[Gretl-devel] Special restriction syntax in VECM doesn't work anymore

Sven Schreiber svetosch at gmx.net
Tue Feb 9 13:26:46 EST 2016

Am 09.02.2016 um 18:47 schrieb Allin Cottrell:
> On Tue, 9 Feb 2016, Sven Schreiber wrote:
>> Am 09.02.2016 um 17:25 schrieb Allin Cottrell:

>>> The test that's generating the error is as follows:
>>> 1. Is cols(R) equal to the total number of elements of beta and alpha
>>> ("gmax"), in the system? In this case the answer is No, since cols(R) =
>>> 20 and gmax = 40.
>> I guess you're referring to the internal restriction representation
>> now. Because according to the guide the direct usage of an R matrix is
>> not supported for restrictions on alpha, only on beta.
> Hmm, good point; it seems we shouldn't be accepting cols(R) = gmax in
> the VECM case.

If this refers purely to the user's point of view, then probably not.

>>> 2. If No, is cols(R) equal to the number of beta rows (here, 5)? No
>>> again, so fail.
>> At the risk of revealing my ignorance, right now I'm not getting why
>> this would be an admissible case in general.
> Wouldn't that be OK for a restriction that's in common for all columns
> of beta?

Well, I'm simply looking at equ. (27.5), where cols(R) must be equal to 
the rows of vec(beta), full stop. And except for the special case r==1 
(and leaving aside the possibility of an extended beta^* with restricted 
deterministic and exogenous terms) this cannot be equal to n (rows of beta).

Now, perhaps the case cols(R)==n leads to some other restriction 
formulation, I don't know. We probably discussed this back when the 
whole restricted estimation thing was adapted from Boswijk&Doornik, but 
I don't remember if that's the case.

>> Once the really relevant check is added as you just did apparently,
>> maybe this check number 2 should/could be removed?
> I'll have to think about this some more, but I believe it's check number
> 1 (or gateway #1) that should be removed.

As I have explained above, at the moment I would think the only 
meaningful check is cols(R)==rows(vec(beta)), but I may be missing 

>> Before turning to practical testing, let me raise the issue of
>> exogenous restricted terms which lead to rows(vec(beta_x) = (n+n_x)*r
>> instead of rows(vec(beta)) = n*r. Is that covered by the bugfix?
> Not that I'm aware of 8-/

Hehe, it should be acknowledged that currently the guide isn't very 
clear about whether this is supposed to work at all. OTOH, the apparatus 
for restricting and testing the entire beta^* is there and working. 
(Sorry I'm switching back and forth between beta^* and beta_x to denote 
the same thing.) So I tend to think using the restriction interface 
specifying R*vec(beta^*) = q should be allowed.

So that would mean that the check would be:
1) cols(R) == (n + nrexo) * r , if we are in odd Johansen cases (1,3,5) 
and nrexo is the number of further restricted exogenous variables in the 
2) cols(R) == (n + nrexo) * r + 1 , if we are in even Johansen cases (2,4).


More information about the Gretl-devel mailing list