Re: [Gretl-devel] VECMs with holes
The problem here is that you always need the lagged levels in a VECM for
the error correction term, and that the gaps would normally or
implicitly refer to the lagged differences.
Eviews circumvents this problem by adopting different conventions for
VARs und VECMs: In VARs the lag order refers to levels, in VECMs to
differences. So the gap specification is easy there.
Right now I'm not sure what the best solution would be. I don't think it
would be good to switch over the the lagged-differences-convention for
VECMs just to have gappy lags. Or would it?
So maybe it would be best to leave things as they are...?
I'll try to think about it some more.
cheers,
sven
Allin Cottrell schrieb:
In response to Sven's request not so long ago I enabled
specification of particular lags of the y variables in VARs (e.g.
you could have a VAR with lags 1 and 3, skipping 2).
I said I'd follow up by allowing that sort of thing for VECMs too,
but unless I'm getting mixed up (quite possible) this seems
substantially more difficult.
Consider the gappy VAR (deterministic terms and error omitted for
simplicity):
y_t = A_1 y_{t-1} + A_3 y_{t-3}
The VECM representation is, I think,
\delta y_t = \Pi y_{t-1} + G_1 \delta y_{t-1}
+ G_2 \delta y_{t-2}
where \Pi = A_1 + A_3 - I
G_1 = -A_3
G_2 = -A_3
That, not only have we "dropped a lag" (as per usual), but now
there's an implied restriction on the G_i matrices. First
question: have I gone off the rails here? Second Q: if not, how
would we handle this and would it be worth the trouble?
Allin.
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel