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

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?

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?