implicit inversion with pos-def matrices
by Sven Schreiber
Hi all, this is a question about the "matrix division" operators / and
\. As explained in the guide section 17.5, they can replace the pre- or
post-multiplication with an inverse (and more). So A * inv(B) will be
equal to A / B up to numerical error.
Typically this implicit way is recommended over explicit inversion for
numerical stability and also speed, I think. But what about the special
case with positive-definite matrices and invpd() ? I was going to use /
and \ there as well, but the following simple test showed that it's slower.
<hansl>
M = mnormal(50,10)
MM = M'M
pre = mnormal(20,10)
iter = 1000
set stopwatch
loop iter
m1 = pre * invpd(MM)
endloop
print $stopwatch
loop iter
m2 = pre / MM
endloop
print $stopwatch
print m1 m2
</hansl>
The second version takes about 2-3 times longer here. (But I know that
such stuff can heavily depend on the matrix sizes.)
Basically the question is: do we need specialized variants of / and \
for pos-def. arguments? Or is there nothing to be gained over the
explicit inversion with invpd?
thanks
sven
1 month
Weird (buggy?) behavior with min()/max() with no dataset in place
by Artur T.
Using latest snapshot,
Calling min() and max() with no dataset in place returns the error:
<error>
? eval min(m)
No dataset is in place
Terminated on error
</error>
Simply execute the following:
<hansl>
matrix m = seq(1,4)
# both fail
eval min(m)
eval max(m)
# works
eval maxc(m)
eval maxr(m)
</>
This must be due to a recent change, as I just ran a script which worked
before.
Best
Artur
1 month
how to run auxiliary estimation commands inside functions
by Sven Schreiber
Hi all,
when programming some stuff with Hansl functions, one of the recurring
problems is that gretl's estimation commands work on series and list
types, not on matrix stuff. (And yes, I know about mols().) Even after
all these years it's not always clear to me how to work around this
limitation, especially when auxiliary estimation routines are performed
on kind of interim data (matrix-es) that do not really correspond well
to the incoming dataset from the outer scope.
Let me give an arbitrary example which does not work:
<hansl>
# test an aux dataset inside a function
function void internalar (matrix x, int p)
x = vec(x)
T = rows(x)
nulldata T # not allowed -> error
setobs 1 1 --time-series
series s = x
ar p ; x
end function
open abdata # panel dataset just for the heck of it, but can be omitted
internalar(mnormal(50), 2)
</hansl>
In this example, I cannot use gretl's "ar" estimation command inside the
function. (This is just an example, the question is about other commands
as well, so please no answers on how to perform the equivalent by hand.)
Any fairly general hints and ideas on how to overcome this kind of problem?
thanks
sven
1 month
Problems reading ods data type
by Artur T.
Hi,
I have an issue with opening an ods-file (attached). The following error
is thrown when trying to open the file (either via GUI or script):
Interestingly, the xlsx-equivalent does not provoke an error and gets
loaded properly.
I am using a recent gretl snapshot from last week on Ubuntu.
Just another minor thing: While drag-and-drop works for the xls(x) file
type, it fails for ods. Might be a bug or simply not supported (which
would be totally fine).
Best,
Artur
1 month
spurious description string in pointerized series arg
by Sven Schreiber
Hi,
the attached script files demonstrate a bug. Please run the
bugtest_driver.inp script which includes the other script
port_bugtest.inp. The example uses the built-in example dataset abdata.
The point is that the top-level series "e" which is passed as a pointer
arg to the function (factcoint_test) gets a spurious and more or less
arbitrary description string, sometimes including non-printable
characters. Actually sometimes the correct description happens; in that
case please just run the script again. To trigger the bug it seems
necessary to have an enclosing loop.
In itself it's not a big deal, but since apparently chunks of memory end
up where they do not belong, maybe some related unknown bugs exist and
may be fixed by getting this straight.
This is a fairly recent snapshot.
thanks
sven
1 month
problem scanning a string with commas
by Sven Schreiber
Hi,
maybe I'm not literate enough with the sscanf function, but the
following example is giving a result which I did not expect. Is it a
bug, maybe triggered by the included comma?
<hansl>
string hey = "aha oho, uhu"
string s
sscanf(hey, "aha %s", s) # expected: "oho, uhu"
print s # gives "oho,"
</hansl>
This is a recent snapshot, but I guess if it's really a bug, then it's
not new.
thanks
sven
1 month, 1 week
Re: GUI small bugfix
by Artur T.
Am 16.09.25 um 17:34 schrieb Artur T.:
> Am 16.09.25 um 16:23 schrieb Riccardo (Jack) Lucchetti:
>> While playing with the new vecm goodies, I noticed that the
>> "Graph>Residuals>Multiple plot" entry had a little problem for system
>> with 5 or 6 variables, which I just fixed in git.
>>
>> While I was at it, I allowed that plot for systems up to 9 variables
>> (previous limit was 6), that looks reasonable to me given the size of
>> modern screens.
>
> Hi Jack,
>
> the attached file is with latest snapshot (just recompiled gretl). The
> space between subplots is large, and hence the figures do not look
> that useful here.
Hi Jack,
Gretl is definitely correctly compiled. But the multiplot for 7
residuals doesn't look that nice. See attached the overlapping of axis
tics and space between subplots.
Artur
1 month, 2 weeks
Re: GUI small bugfix
by Artur T.
Am 16.09.25 um 17:34 schrieb Artur T.:
> Am 16.09.25 um 16:23 schrieb Riccardo (Jack) Lucchetti:
>> While playing with the new vecm goodies, I noticed that the
>> "Graph>Residuals>Multiple plot" entry had a little problem for system
>> with 5 or 6 variables, which I just fixed in git.
>>
>> While I was at it, I allowed that plot for systems up to 9 variables
>> (previous limit was 6), that looks reasonable to me given the size of
>> modern screens.
>
> Hi Jack,
>
> the attached file is with latest snapshot (just recompiled gretl). The
> space between subplots is large, and hence the figures do not look
> that useful here.
I guess, I haven't compiled gretl properly. Sorry. First I need to
update gretl correctly. Will come back to this later.
Artur
1 month, 2 weeks
GUI small bugfix
by Riccardo (Jack) Lucchetti
While playing with the new vecm goodies, I noticed that the
"Graph>Residuals>Multiple plot" entry had a little problem for system
with 5 or 6 variables, which I just fixed in git.
While I was at it, I allowed that plot for systems up to 9 variables
(previous limit was 6), that looks reasonable to me given the size of
modern screens.
Aliin: if you disagree, feel free to revert, of course.
--
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1 month, 2 weeks
panel time spuriously carries over to new dataset
by Sven Schreiber
Hi,
a marginal thing, but still not right I'd say:
<hansl>
open abdata # time starts at 1976
nulldata 10
setobs 2 1:1 --stacked-time-series # still 1976??
</hansl>
I would expect that "nulldata" also clears the panel time information.
thanks
sven
1 month, 2 weeks
