Allin Cottrell schrieb:
>> The final "restrict" command produces nice results.
But what has
>> gone wrong in the previous case? Clearly the automatic initial
>> values computed by gretl were bad. But can anyone test this
>> against other software and see if the competition gets it right?
>> That would be very helpful.
> I would, but I will be traveling the next 2-3 weeks.
OK, hope to hear from you later!
Ok, hope you don't miss this belated continuation of the thread.
Before tackling the restrictions, maybe it's worth noting that for the
unrestricted Vecm I get the same point estimates with gretl (snapshot
downloaded today), Eviews (5.1), and PcGive (10.4), but three different
sets of standard errors:
beta (cointegrating vectors, Standardfehler in Klammern)
Standard errors of beta
Now turning to the restrictions in the top post:
Eviews and PcGive produce the correct results, saying "6 iterations" and
"strong convergence" (with settings eps1=0.0001) respectively. They are
identical to each other and also match gretl's output, except for the
standard errors of the adjustment coefficients which are a little
smaller in gretl.
Do you do any scaling before the switching algorithm? The beta
coefficients differ by a factor of 6 (haven't looked at the
--detrended-- variables themselves), maybe that explains something. (I
always used the gretl example data exported to the other formats, so
maybe there's also some conversion loss, but I doubt it.)
By the way I also tried with my unpublished py4gretl_vecmrestrict2 (the
published version w/o the 2 at the end cannot handle this case), but I
don't get any results, but no error message either. So some other
function-package related bug must be lingering there, but leave that for