Indeed I had forgotten about the CLI! Your solution looks very natural
and should certainly be general enough. For more flexibility I think it
is ok to refer people to the general simultaneous system approach.
so thanks once again for a quick reaction,
Allin Cottrell schrieb:
On Fri, 30 Jan 2009, Sven Schreiber wrote:
> Allin Cottrell schrieb:
>> On Thu, 29 Jan 2009, Sven Schreiber wrote:
>>> And while we're (or I'm) at it, couldn't this flexible approach
>>> choosing lags also be extended to endogenous variables?
>> Sorry, not sure what you mean: do you want "gappy" VARs/VECMs
>> with holes in the lag order?
> Yes. The state of the "competition" is as follows AFAIK:
> Eviews can have holes in the lag order, but only one lag specification
> for all variables.
> With PcGive/Oxmetrics you can choose the lags separately for each
> variable; I don't remember right now if that requires the specification
> of a "model" (in their parlance) instead of a VAR, but I don't think
The Eviews variant (holes allowed, but only one pattern for all
endogenous variables) sounds complicated enough to be going on
with. This is now implemented (at beta-test level) in CVS, as
follows (but at present only for plain VARs; VECMs should follow):
* script syntax: to a specification of the current sort, such as
var 4 y1 y2 y3 [; x1 x2 ]
you can now add "--lags=<lagspec>", e.g.
var 4 y1 y2 y3 --lags=1,2,4
which has the effect of using (only) the lags in <lagspec> for the
endogenous variables. The syntax for <lagspec> allows
comma-separated specific lags, as in the example above, and also
abbreviated contiguous ranges of lags, using '-'. For example,
is equivalent to
There must be no spaces in this sort of lag specification, as
* GUI version: There's a "lags..." button next to the box holding
the endogenous variables for a VAR. You can click this for finer
control over the lag specification than using the "lag order"
spinner. If you enter specific non-contiguous lags in the dialog
box, the lag order spinner becomes disabled (but continues to
display the maximum lag selected).
Note that the leading "order" integer in the VAR command continues
to bind. In other words, if you do
var 4 y1 y2 y3 --lags=1,2,3,8
you will get a VAR with lags 1, 2 and 3 (since lag 8 is cut off by
the "order" specifier of 4). This allows you (e.g.) to trim an
initial lag specification (e.g. given by a string variable), in a
Gretl-devel mailing list