On Mon, 29 Apr 2013, Sven Schreiber wrote:
Ok, so I remembered some things correctly (see below), but indeed
had
forgotten the most important part: It's already there! Just push the
"lags" button in the VAR specification dialog and enter your individual
lag structure (comma-separated I think).
See
http://lists.wfu.edu/pipermail/gretl-devel/2009-February/001682.html
for the original discussion, already four years ago... time passes
quickly...
It remains to be said that the CLI version is still undocumented at
least in the online help.
Thanks for chasing this down, Sven.
The CLI counterpart to the special use of the "Lags" button in
the GUI is appending an option string of the form
--lags=<lags>
e.g.
--lags=1,2,4 # or --lags="1,2,4"
The reason this has never been documented is that it was a
quick-and-dirty hack. It's not nice to have a lag order as the
first argument to the "var" command plus an option to specify
lags at the end. The right way to do this would be to allow
use of the name of a matrix in place of the scalar "order"
argument, as in
matrix p = {1,2,4}
var p Ylist
I guess, though, that implementing that functionality has not
seemed like a high priority to date.
Anyway, as things stand, if one wants to use the libgretl API
to estimate a VAR with "gappy" lags one has to emulate the
setting of the "--lags=..." option, as in
<C>
GRETL_VAR *v;
int err = 0;
set_optval_string(VAR, OPT_S, "1,2,4");
v = gretl_VAR(4, Ylist, dataset, OPT_S, prn, &err);
</C>
Note that this is not guaranteed to be stable API. If we get
around to allowing a matrix argument for the lag order the
clunky OPT_S business may disappear.
Allin Cottrell