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

Sven Schreiber svetosch at gmx.net
Tue Feb 9 11:46:05 EST 2016


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.

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

>
> The missing test seems to be: does cols(R) equal the full number of
> elements in the beta matrix? (Which it does here.) If so, go ahead. I'm
> inserting this test in git; it would be good if it gets some testing.
>

Yes I also think this is the relevant check. And now I believe that my 
old code had worked because it fell under the special case r=1, see above.

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?

thanks,
sven


More information about the Gretl-devel mailing list