I've been working on the manual to update the matrix chapter. Only now I
realise that there is some inconsistency in the way dollar accessors are
used, with respect to variances/covariances after estimation.
Typically, after a model is estimated, we use $sigma for the residuals and
$vcv for the parameters. However, this is not always the case; some
exceptions are well justifed, some less well.
After estimating a system, $sigma holds the covariance matrix of the
residuals and $vcv the covariance matrix of the parameters of the
structural form; this is nice and consistent with, say, ols, but is _not_
consistent with VAR/VECM estimation, where $vcv holds the cov. mat. for
the residuals and $sigma is unused. Moreover, we have an accessor ($h)
only used for garch estimation, which does the same job as $sigma (which
is unused for garch models), when you take into account that the estimate
of the conditional variance is not a scalar but a series in these models
by their very nature.
In order to fix things here, some backward-incompatible changes are
needed. If you ask me, I'd use $sigma for VAR/VECM/GARCH models
throughout; I'd scrap $h; I'd implement $vcv as the covariance matrix of
parameters for VARs. Clearly, this would definitely break a few existing
My question to you is: do you agree with the above? I won't touch the
source anyway before Monday, because what matters in the end is Allin's
opinion (that's what benevolent dictators are for). However, what you guys
think is very important too. So, even if you don't have a strong opinion
on this, please reply!
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
I've been working lately on some functions contributed by Ignacio,
and to make things easier for debugging I've added a few small
features; they'll be documented shortly.
* There's a new "set" variable, "debug". Turning this on is
equivalent to setting "echo on" and "messages on" in all functions
that are called. (The default is to suppress echo and messages
* When a function has a "bool" parameter, we adjust the user input
so that it's all zeros and ones. That is, any non-zero values
(apart from NA) are converted to 1s.
* In the GUI editor for function packages there's a new button
"Save as script". This saves the package as a regular gretl
script, containing the public interface and any auxiliary
I've also fixed a couple of bugs: the case where a "pointer"
parameter for a user-defined function has "null" as an option was
not handled correctly; and the use of the "smpl" command with
variables given for the starting and ending points of the sample
range was broken (I'm not sure how I missed that one, and I'll
make sure there's an example in the gretl test suite).
I tried to access the single values of the $coeff array directly with the
a = $coeff[x,1]
that is a usage of the $coeff array not mentioned in the command reference,
but anyway it is supposed to return a scalar. On the contrary it returns a
Obviously by priorly assigning the array of coeff to another vector and then
accessing the second one everything works fine.
Or rather, even more simply, i could specify the new variable as scalar
scalar a = $coeff[x,1]
but here another inconvenient raises. If I try to print the variable a
without explicitly using the print command, after a few runnig of the same
script gretl crashes.
To clarify things here is a stupid script, that if is launched a few times
in succession causes Gretl to crash. The number of launches before crashing
appears to be quite random.
a = uniform()
b = uniform()
ols a const b
genr cc = $coeff(b)
By the way it could be nice to access the coefficients in the array with a
command like $coeff( number), useful if you don't know the name of the
Current CVS contains this experimental feature: when gretl
encounters a genr-type command within a loop, then on
condition that no string substitution has been done on the line
(and that include $i-type substitution) it "compiles" the genr
expression once and re-uses it on subsequent iterations of the
(If string substitution has been done, we can't assume it will
"the same genr" the next time round.)
The idea, of course, is to speed up loop execution. While I've
done a certain amount of testing (which seems to show quite a
handy speed-up), it's quite likely there are problem cases that I
haven't thought of yet. If you want to turn off this behavior,
open lib/src/monte_carlo.c in a text editor and change
#define GENCOMPILE 1
#define GENCOMPILE 0
But if you'd like to test the new behaviour, that would be great.
Currently, if I define a function like:
function func ( series a, scalar b[1:2:1], bool c, list d[null])
I'm supposed to be able to call the above-mentioned function with something
a = uniform()
a = func(a)
and Gretl is supposed to assign the default values to the scalar b and the
boolean c, and at the same time, gretl should tolerate the absence of the
list d as parameter. The logic is "I omitted the parameters because I know
what I'm doing".
Currently, Gretl complains about the lack of the parameters
func: not enough arguments
Command has insufficient arguments
where the error is due only to the absence of the list.
I know that the [null] identifier in the definition of the function means
that the list may be empty (not missing) but actually the script works fine
even without the [null] tag when any empty list is passed.
So, it might be thought to tolerate missing parameters if the absence
doesn't compromise the usability of the function itself. Obviously some
convention should be introduced on the subject. The same idea could be valid
for series and matrix as well.
I know this feature-request is not a top priority, but I just wanted to
point out something that could be useful to extend the gretl scripting
I think I've asked about it before, but the "big" feature I'm missing in
gretl is the Kalman filter for state-space models.
I'm asking again not because I want to sound pushy but because last time
I asked it seemed to me that it was mostly an issue of inventing a
syntax for how to invoke it; the native engine is already in gretl AFAIK.
If that's true, do you want to hear syntax proposals? Or is there any
other way that people can help (without messing with the C source)?
I just updated the source and apparently something has changed because now
opening any native Gretl data file returns an error like the following:
Data file is empty
Error executing script: halting
> open mroz
The same for djclose, sw_ch14..and any other file. Anyway if I try to access
them by the menu Gretl opens them without problems. Even stranger, if i give
the complete path with a command like
open /usr/local/share/gretl/data/misc/mroz.gdt [ and the file does exist]
it returns the same error
Dear gretl developers,
I recently installed Fedora 9 (preview). I cannot install the rpm since it complains that libreadline.so.4 is not provided. That issue I had as well on Fedora 8 but there the compilation did work then.
Now with Fedora 9 the compilation of gretl 1.7.4 fails. The ./configure went well with:
Installation path: /usr/local
Use readline library: yes
Use gnuplot for graphs: yes
Use PNG for gnuplot graphs: yes
Use LaTeX for typesetting output: yes
Gnu Multiple Precision support: yes
MPFR support: yes
LAPACK support: yes
FFTW3 support: yes
Build with GTK version: 2.0
Script syntax highlighting: yes
Use installed gtksourceview: no
Use GTK printing apparatus: yes
Build with gnome support: 2.0
Build gretl documentation: no
Use Lucida fonts: no
Build message catalogs: yes
Gnome installation prefix: /usr
X-12-ARIMA support: yes
TRAMO/SEATS support: yes
Experimental audio support: no
Now type 'make' to build gretl.
The compilation starts but halts then at:
make -C gtksourceview
make: Entering directory `/home/sgrosse/Downloads/gretl-1.7.4/gui2/gtksourceview'
gcc -g -O2 -I../../gui2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -DDATADIR=\"/usr/local/share/gretl\" -DNATIVE_GNU_REGEX -c -o gtksourceregex.o gtksourceregex.c
gtksourceregex.c:43: Fehler: Feld »reg« hat unvollständigen Typen
gtksourceregex.c: In Funktion »gtk_source_regex_compile«:
gtksourceregex.c:56: Fehler: »RE_SYNTAX_POSIX_MINIMAL_EXTENDED« nicht deklariert (erste Benutzung in dieser Funktion)
gtksourceregex.c:56: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt
gtksourceregex.c:56: Fehler: für jede Funktion in der er auftritt.)
gtksourceregex.c:57: Fehler: »struct re_pattern_buffer« hat kein Element namens»translate«
gtksourceregex.c:58: Fehler: »struct re_pattern_buffer« hat kein Element namens»fastmap«
gtksourceregex.c:59: Fehler: »struct re_pattern_buffer« hat kein Element namens»allocated«
gtksourceregex.c:60: Fehler: »struct re_pattern_buffer« hat kein Element namens»buffer«
gtksourceregex.c:64: Warnung: Zuweisung erzeugt Zeiger von Ganzzahl ohne Typkonvertierung
gtksourceregex.c:69: Fehler: »struct re_pattern_buffer« hat kein Element namens»fastmap«
gtksourceregex.c:70: Fehler: »struct re_pattern_buffer« hat kein Element namens»fastmap«
gtksourceregex.c:75: Fehler: »struct re_pattern_buffer« hat kein Element namens»fastmap«
gtksourceregex.c: In Funktion »gtk_source_regex_destroy«:
gtksourceregex.c:88: Fehler: »struct re_pattern_buffer« hat kein Element namens»fastmap«
gtksourceregex.c:89: Fehler: »struct re_pattern_buffer« hat kein Element namens»fastmap«
gtksourceregex.c: In Funktion »gtk_source_regex_search«:
gtksourceregex.c:135: Fehler: »struct re_pattern_buffer« hat kein Element namens »not_bol«
gtksourceregex.c:136: Fehler: »struct re_pattern_buffer« hat kein Element namens »not_eol«
gtksourceregex.c: In Funktion »gtk_source_regex_match«:
gtksourceregex.c:184: Fehler: »struct re_pattern_buffer« hat kein Element namens »not_bol«
gtksourceregex.c:185: Fehler: »struct re_pattern_buffer« hat kein Element namens »not_eol«
make: *** [gtksourceregex.o] Fehler 1
make: Leaving directory `/home/sgrosse/Downloads/gretl-1.7.4/gui2/gtksourceview'
make: *** [gtksourceview/libgtksourceview-lite.a] Fehler 2
make: Leaving directory `/home/sgrosse/Downloads/gretl-1.7.4/gui2'
make: *** [gui2] Fehler 2
Sorry for the German locale.
I do not know what I can do now to compile. Any suggestions?