[Gretl-devel] VECM restrictions once again

[Sven Schreiber]

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:

gretl:
beta (cointegrating vectors, Standardfehler in Klammern)

LRM(-1)           1.0000
                (0.00000)
LRY(-1)          -1.0329
                (0.12805)
IBO(-1)           5.2069
                (0.50735)
IDE(-1)          -4.2159
                 (1.0051)
const            -6.0599
                (0.79464)

Eviews:
	
LRM(-1)	 1.000000
	
LRY(-1)	-1.032949
	 (0.13897)
	[-7.43297]
	
IBO(-1)	 5.206919
	 (0.55060)
	[ 9.45682]
	
IDE(-1)	-4.215879
	 (1.09082)
	[-3.86489]
	
C	-6.059932
	 (0.86239)
	[-7.02691]

PcGive:
beta
LRM                 1.0000
LRY                -1.0329
IBO                 5.2069
IDE                -4.2159
Constant           -6.0599

Standard errors of beta
LRM                0.00000
LRY                0.14054
IBO                0.55682
IDE                 1.1031
Constant           0.87213



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
another time...

HTH,
-sven