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

Allin Cottrell cottrell at wfu.edu
Tue Feb 9 12:47:00 EST 2016


On Tue, 9 Feb 2016, Sven Schreiber wrote:

> Am 09.02.2016 um 17:25 schrieb Allin Cottrell:
>> On Tue, 9 Feb 2016, Sven Schreiber wrote:
>>> 
>>> This is on gretl 2016a, and the hansl code where I noticed the problem
>>> first is not new, so I'm relatively sure that this used to work last
>>> year (as it should).
>>> 
>>> Any ideas?
>> 
>> Are you sure this worked before? I just tested with gretl 1.9.14
>> (2013-11-21) and it failed in the same way (supposed non-conformability).
>
> The code area of the respective script of mine was definitely not new. 
> However, without further investigation and recapitulation I cannot say for 
> sure whether that code area really had been executed. -- Also, see below for 
> what possibly was a special case.
>> 
>> 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.

>> 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?

> What I can see is that in the special case of r=1, rows(beta) == number of 
> total beta elements (==rows(vec(beta)), and so for r=1 this is a check of 
> whether the matrix multiplication R*vec(beta) is defined, corresponding to 
> eq. (27.5) of the user guide.
>
> 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.

> 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-/

Allin


More information about the Gretl-devel mailing list