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