Re: [Gretl-devel] missing deterministics in $system.xlist
On Sat, 9 Feb 2019, Sven Schreiber wrote:
I've noticed that the list of exogenous terms of a VAR system via
the $system.xlist accessor does not include 'const'. This is in
contrast to the $xlist analogue after ols.
Also, while the trend term is not included in $system.xlist when the VAR is
estimated with the --trend option, if instead I specify something like:
var 2 X Y ; time
then 'time' shows up in $system.xlist.
I can actually understand the rationale: Only explicit terms are included.
However, that is also not 100% true, because even after the redundant thing
here...:
var 2 X Y ; const
the $system.xlist is still empty and doesn't show const.
It would be useful if the exact specification of the VAR could be
read off the $system accessor. Right now I only see the workaround
to look at the first column of the matrix $system.X.
OK, I see what you mean. I've now added to the $system accessor for
VARs and VECMs a 3-vector named "detflags" (deterministics flags).
The first element is 1 if the specification contains a constant, 0
otherwise; the second is 1 if the --trend option is given, 0
otherwise; and the third is 1 if the --seasonals option is given, 0
otherwise.
The recommended way of specifying these points is via the options,
with a constant being assumed automatically unless the --nc option
is given.
There's one "hole" in this: if the user puts "time" into the
exogenous vars list instead of using the --trend option that won't
get picked up (as a 1 for detflags[2]) at present. There's a reason
for that. As things stand, although "genr time" gives you a trend
variable named "time" there's nothing stopping a user from using the
name "time" for something else altogether, as in
series time = normal()
Maybe that should be banned, but it seems to me the fewer the
reserved words, the better. We could examine "time", if it's given
as a VAR exogenous term, to see if it's really a linear trend,
though that seems a little like rewarding bad behaviour.
And while we're at it: The doc for $system says:
"...referenced by
keys that are the same as the regular accessor names".
- But instead of $system.compan we have $system.A.
I hadn't noticed that. We could rename $system.A as $system.compan,
but I guess at this point that would be a backward-incompatible
change. I'm open to suggestions.
Allin