Re: [Gretl-devel] coint2 with exogenous variables
On 11/05/2011 09:35 PM, Allin Cottrell wrote:
On Sat, 5 Nov 2011, Andreas Noack Jensen wrote:
> Den 04/11/2011 kl. 18.16 skrev Allin Cottrell:
>
>> So I'll try to track down
>> the source of the difference with Tr76 added.
>
> I have looked at the problem again and found the error. It is an
> easy fix, I guess. The restricted variables are lagged one period.
> For that reason the sample is also changing if the restricted
> variable is excluded. The attached modified script gives exactly
> the same results in Gretl and Ox.
Yes, I came to the same conclusion, and I've just committed a change
to gretl CVS that renders the results the same (from gretl and Ox)
for your original script.
I'm not sure but could it be that we had discussed the question of
whether the exogenous restricted variables should be lagged or not?
Ultimately it's a matter of convention, of course, but what I may have
argued back then is this: since the error correction term also (usually)
appears with a t-1 index, I'd say it's not wrong to include x_{t-1}
instead of x_t.
> As a side note I have a small suggestion. It is unfortunate to
> test cointegration rank in the models with unrestricted
> deterministic terms so maybe they should not be there. If you
> really want to work with a model with unrestricted terms after a
> rank test procedure you can just make the exclusion restriction on
> he cointegration vectors and I think that is the "right" way to
> end up in that model. At least I shall suggest that the default is
> one the models with restricted terms.
You're suggesting that we shouldn't allow including unrestricted
deterministic terms in cointegration testing (though we should allow
them in VECM specifications, having determined cointegrating rank)?
I think you must take into account that he has been trained in
Copenhagen... They put a lot of emphasis on separating the cointegration
rank determination from the specification of the deterministics. We can
discuss this further if you like, but I am certainly strongly against
disabling some of the possible test setups. Note that the most
widespread case of an unrestricted constant also belongs to that category.
When it comes to changing the default, my feelings are not that strong,
OTOH.
thanks,
sven