Current gretl CVS and the Windows snapshot at
contain release candidate 1 for gretl 1.7.6.
Please note that this version involves a backward-incompatible
change with respect to gretl 1.7.5 and earlier, affecting
user-defined functions that (a) take a named list of variables as
an argument and (b) do things with the list-member variables by
means of a "foreach" loop on the list.
I won't go into the rationale for this change here. Anyone who
wants the details may look at the proceedings on the gretl-devel
list for July, which were mostly taken up with this issue:
There's also a brief discussion in the chapter of the User's Guide
that deals with user-defined functions. But here's the bottom
line for users:
* If you want to "get hold of" a list-member variable in the
context noted above, you have to use the syntax listname.varname,
where listname is the name of the list in question and varname is
the name of the list member. (This is required only if you're
working with a list that was supplied as a function argument.)
Trivial example: inside a function, creating new variables which
are the cubes of the members of an original list, xlist, where
xlist is an argument to the function.
loop foreach i xlist
$i_3 = $i^3
loop foreach i xlist
$i_3 = (xlist.$i)^3
In the new scheme, "$i" gets the name of the list-member variable
alright, but the variable is not "visible" under that name within
the function. So on the right-hand side of the expression that
creates the cubes, we need "(xlist.$i)^3". (Well, actually the
parentheses are not required, but wearing your seatbelt is in
general a good idea.)
Although this may affect quite a large number of existing
functions, we believe the effects are localized and the update
should be trivial. If anyone has a function for which the update
is _not_ trivial, please let us know.
Sorry to ask a "simple and stupid" question on the list, but couldn't find
an answer from any Manual or Command reference (nor Gretl-wiki search).
Is there a simple way to perform out-of-sample forecast for a cross section
In addition to my own work @ Orava RES, I'm a part-time lecturer at the
Aalto University (formerly Helsinki University of Technology) and my
intention is to use Gretl on "Quantitative Methods for Real Estate
Economics" course: students will be required to do their course assignment
using Gretl - and as an old E-Views user I'm just learning how to use Gretl
Head of Information Services & Research
Orava Real Estate Securities Plc
Kanavaranta 7 C
FI-00160 Helsinki, Finland
Tel. +358 10 420 3103
Mobile +358 50 437 2373
Fax +358 9 698 0310
This e-mail is confidential and intended only for the person to whom it s
addressed. It should not be read, copied or used by anyone other than the
intended recipient. Should you have received this message by mistake, please
note that any disclosure, reproduction, distribution or use of this message
or the attachments is prohibited. If you are not the intended recipient
please notify the sender and delete the message without opening or copying
On Sat, 16 Oct 2010, Allin Cottrell wrote:
> On Fri, 15 Oct 2010, Henrique Andrade wrote:
> > Let me explain better: I would like to make the forecasts for the
> > 1972:1-1991:4 period. For 1972:1-1991:1 I would like to use the static
> > option (because I have the data), and for 1991:2-1991:4 I would like
> > to use the dynamic option...
> As you say, it looks as if just doing
> fcast 1972:1 1991:4
> should produce the same results as first doing an explicitly
> static forecast over the estimation range, then calling fcast
> again, with the --out-of-sample flag. I'll look into this.
Henrique saw a difference between the out of sample VAR forecast
values (a) when using the --out-of-sample option with the "fcast"
command and (b) when giving fcast a range of dates which included
both in-sample and out-of-sample periods.
This was due to an ambiguity over exactly when, in the case of a
dynamic forecast, we should start using prior forecast values for
the regressors as opposed to actual data values -- this point
ended up being different in cases (a) and (b) above.
This ambiguity is now resolved. If a dynamic forecast (or the
dynamic portion of a longer forecast) starts in, say, 1991:2 what
we do when computing the forecast for t is this: for each lag, k,
of the right-hand side endogenous variables, check whether t - k
is before 1991:2. If so, use the actual data; if not, use a
previously computed forecast value instead.
This is equivalent to setting all values of the right-hand side
endogenous variables to NA from the starting period of the dynamic
forecast onward (if they're not already NA), and, in forming
forecasts, using actual data whenever possible and prior forecasts
I will be out of the office starting 10/16/2010 and will not return until
Hi All, I will be out of the office from Oct 18 through Oct 21, returning
Oct 22. I will be checking mail in the evenings daily. Please, if you have
an immediate concern regarding Cost Model or Construction Economics, please
email us or contact Brad A Njus, 510 625 4595, with your questions.
On Fri, 15 Oct 2010, Henrique Andrade wrote:
> Let me explain better: I would like to make the forecasts for the
> 1972:1-1991:4 period. For 1972:1-1991:1 I would like to use the static
> option (because I have the data), and for 1991:2-1991:4 I would like
> to use the dynamic option...
As you say, it looks as if just doing
fcast 1972:1 1991:4
should produce the same results as first doing an explicitly
static forecast over the estimation range, then calling fcast
again, with the --out-of-sample flag. I'll look into this.
On Fri, 15 Oct 2010, Henrique Andrade wrote:
> I'm trying to perform forecasts using a VAR model. Please take a look
> at the following script:
> open australia.gdt
> "VAR 1" <- var 1 E PAU PUS
> fcast 1991:2 1991:4 --out-of-sample
The data end in 1991:1. You'll have to use
dataset addobs 3
to add an extra three observations.
In addition, the option --out-of-sample is an alternative to
specifying starting and ending dates. So after adding 3
observations you can do EITHER
fcast 1991:2 1991:4
but you can't combine the two.
On Fri, 15 Oct 2010, Allin Cottrell wrote:
> The names of your graphs contain the XML-special characters '&'
> and '<' and these are not being escaped correctly. We'll see about
> fixing that.
This is now fixed in CVS and snapshots.
On Fri, 15 Oct 2010, Summers, Peter wrote:
> Update: I get the same error with a session that doesn't involve
> edited plots - just a couple of multiple time-series graphs (ie,
> separate small graphs).
The names of your graphs contain the XML-special characters '&'
and '<' and these are not being escaped correctly. We'll see about
fixing that. In the meantime if these session files are important
you can do:
Then open .sessionname/session.xml in a text editor and, in the
names of the graphs, replace '&' with "&" and '<' with "<".
zip -r sessionname.gretl .sessionname
to rebuild the session file.
Update: I get the same error with a session that doesn't involve edited plots - just a couple of multiple time-series graphs (ie, separate small graphs).
I created a session file yesterday that included some graphs that I'd been editing. Now though, I can't re-open the session. Gretl says "xmlParseFile failed on .graphs of components\session.xml", and I can open other sessions with no problem. So I'm guessing this has to do with the edited plot commands? I've attached a copy if that helps.
Dr. Peter Summers
Department of Economics
Texas Tech University