7:48 p.m.
Hi,
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.
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.
- $system.vma is also missing, but we already talked about the
peculiarity of the $vma accessor...
thanks,
sven
10:21 p.m.
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
10:40 a.m.
Am 15.02.2019 um 23:21 schrieb Allin Cottrell:
On Sat, 9 Feb 2019, Sven Schreiber wrote:
> 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.
Thanks, Allin. I have to check (when the my version /snapshot is
updated) what happens in the VECM case. I don't remember exactly where
the list of restricted terms shows up in $system. (Or in $model?)
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.
I think that's OK, because indeed it is not the recommended way.
(Although I think we do something with "time" internally in SVAR or at
least check it. But that can be changed.)
series time = normal()
Maybe that should be banned, but it seems to me the fewer the reserved
words, the better.
Maybe "genr time" should be deprecated, given that "genr index" is
equivalent (or isn't it?). In general I thought the few special genr
expessions (unitdum, index, dum...) were supposed to be replaced with
accessors or other functions eventually.
exogenous term, to see if it's really a linear trend, though that
seems
a little like rewarding bad behaviour.
Yes, no need.
> - 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.
Couldn't one simply be introduced as an alias for the other?
thanks,
sven
2:06 p.m.
On Sat, 16 Feb 2019, Sven Schreiber wrote:
Am 15.02.2019 um 23:21 schrieb Allin Cottrell:
> On Sat, 9 Feb 2019, Sven Schreiber wrote:
>> 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.
>
Thanks, Allin. I have to check (when the my version /snapshot is
updated) what happens in the VECM case. I don't remember exactly where
the list of restricted terms shows up in $system. (Or in $model?)
For a VECM $system bundle b, the following info is available:
b.detflags (includes unrestricted terms only)
b.xlist (unrestricted exogenous vars other than deterministics)
b.rlist (restricted exog. vars other than deterministics)
b.vecm_info.code
xlist and rlist are present only if applicable. The "code" value is
the Johansen case, numbered from 0 to 4: it should probably be
called "jcase" and maybe should be 1-based?
Allin
10:20 p.m.
Am 16.02.2019 um 15:06 schrieb Allin Cottrell:
On Sat, 16 Feb 2019, Sven Schreiber wrote:
> Thanks, Allin. I have to check (when the my version /snapshot is
> updated) what happens in the VECM case. I don't remember exactly where
> the list of restricted terms shows up in $system. (Or in $model?)
For a VECM $system bundle b, the following info is available:
b.detflags (includes unrestricted terms only)
just added a (few) day(s) ago, you mean?
b.xlist (unrestricted exogenous vars other than deterministics)
b.rlist (restricted exog. vars other than deterministics)
b.vecm_info.code
Yes, I see them.
xlist and rlist are present only if applicable. The "code"
value is the
Johansen case, numbered from 0 to 4: it should probably be called
"jcase" and maybe should be 1-based?
Definitely 1-based in hansl, I'd say. I wouldn't worry much about
backward compatibility here, although a mention in the changelog
wouldn't hurt. "jcase" maybe, or perhaps slightly more verbose
"jdetcase" (or shorter "jdet"?).
Speaking about "j", I don't see the analogue of the $jbeta and $jalpha
accessors. I see that $system.vecm_info.Beta is the same as $jbeta, but
I think it should go under $system.jbeta. Same for
$system.vecm_info.Alpha and $jalpha, which should come as $system.jalpha.
Plus $jvbeta isn't directly there, either, but as $system.vecm_info.Bvar.
And then there are the undocumented $S11, $S00 etc. which seem to be
encoded as $system.vecm_info.Suu etc.
So basically what I'm asking for is to make all vecm accessors directly
available as $system members under the same keys, as stated in the docs.
Collecting them in an vecm_info sub-bundle isn't a problem per se, if
the exception gets properly documented as well.
What isn't clear to me is the status of the $vma accessor in this
context. The problem is the dependence on the horizon, which then would
have to be stored as well, I guess.
thanks
sven
2139
days inactive
2147
days old
4 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber