12:58 p.m.
Hi,
I've run into a "matrix not conformable" problem, using the example
restriction code from ch. 27 (p. 237 in my A4 PDF version dated January
2016):
<hansl>
open australia
list vecmvars = PAU PUS E IAU IUS
vecm 2 4 vecmvars
# from here on code snippet from ch. 27 in user guide
matrix I4 = I(4)
matrix vR = I4**(I4~zeros(4,1))
matrix vq = mshape(I4,16,1)
restrict
R = vR
q = vq
end restrict
</hansl>
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?
thanks,
sven
4:25 p.m.
On Tue, 9 Feb 2016, Sven Schreiber wrote:
Hi,
I've run into a "matrix not conformable" problem, using the example
restriction code from ch. 27 (p. 237 in my A4 PDF version dated January
2016):
<hansl>
open australia
list vecmvars = PAU PUS E IAU IUS
vecm 2 4 vecmvars
# from here on code snippet from ch. 27 in user guide
matrix I4 = I(4)
matrix vR = I4**(I4~zeros(4,1))
matrix vq = mshape(I4,16,1)
restrict
R = vR
q = vq
end restrict
</hansl>
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 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.
2. If No, is cols(R) equal to the number of beta rows (here, 5)? No
again, so fail.
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.
Allin
4:46 p.m.
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
5:47 p.m.
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
6:26 p.m.
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
something.
> 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
VECM,
2) cols(R) == (n + nrexo) * r + 1 , if we are in even Johansen cases (2,4).
thanks,
sven
1:49 p.m.
Am 09.02.2016 um 19:26 schrieb Sven Schreiber:
Am 09.02.2016 um 18:47 schrieb Allin Cottrell:
>>> 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.
>>> 2. If No, is cols(R) equal to the number of beta rows
(here, 5)? No
>>> again, so fail.
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).
> 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
something.
Whatever happened to this? In one message you said that you would insert
in git this last check. (Not covering the case of restricted exogenous
terms for the moment.) I'm assuming that's done.
To sum up, my suggestion would then be:
1. Remove the check No. 1 above, because as per the spec restrictions on
alpha are not covered here.
2. Remove the check No. 2, too, because for simplicity I think the spec
for this special restriction interface should not provide extra ways for
common restrictions on all CI relations. (If such a common restriction
is wanted, I'd say it has to be spelt out explicitly in this framework.)
3. Document in the guide that this restriction interface so far does not
allow restricting coefficients of exogenous terms. Introduce a note in
the source (and possibly in the issue tracker) that this feature should
be added.
Or do you want to tackle the last thing right now?
Thanks,
sven
4:48 p.m.
On Wed, 16 Mar 2016, Sven Schreiber wrote:
Am 09.02.2016 um 19:26 schrieb Sven Schreiber:
> Am 09.02.2016 um 18:47 schrieb Allin Cottrell:
>>>> 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.
>>>> 2. If No, is cols(R) equal to the number of beta rows (here, 5)? No
>>>> again, so fail.
> 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).
>> 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
> something.
Whatever happened to this? In one message you said that you would insert in
git this last check. (Not covering the case of restricted exogenous terms for
the moment.) I'm assuming that's done.
To sum up, my suggestion would then be:
1. Remove the check No. 1 above, because as per the spec restrictions on
alpha are not covered here.
2. Remove the check No. 2, too, because for simplicity I think the spec for
this special restriction interface should not provide extra ways for common
restrictions on all CI relations. (If such a common restriction is wanted,
I'd say it has to be spelt out explicitly in this framework.)
3. Document in the guide that this restriction interface so far does not
allow restricting coefficients of exogenous terms. Introduce a note in the
source (and possibly in the issue tracker) that this feature should be added.
Or do you want to tackle the last thing right now?
Just a holding response for now: I agree it's time to resolve this. I
won't have time today but I'll take a proper look at it tomorrow.
Allin
5:12 p.m.
Am 17.03.2016 um 17:48 schrieb Allin Cottrell:
Just a holding response for now: I agree it's time to resolve this. I
won't have time today but I'll take a proper look at it tomorrow.
If you want me to do some testing of the status quo, please tell me.
(Preferably with some directions as in "this and that should work, but
it's not clear if it does".)
I can already say that I used successfully a case where beta was fully
restricted/specified under rank r=2, something which didn't work before
I think.
thanks,
sven
2963
days inactive
3000
days old
7 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber