[Gretl-devel] Special restriction syntax in VECM doesn't work anymore
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
> 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-/
More information about the Gretl-devel