10:30 p.m.
On Tue, 4 Jan 2022, ESTEVEZ NUÑEZ JUAN CARLOS wrote:
Hi Jack,
Your code shows any error message with the Windows-32 zip version
until 2018/05/11, but it fails with 2018/08/11 zip version, and
following. Maybe some was made meanwhile that causes it.
Thanks for this observation!
I'm working on the bug. Following Juan Carlos's observation I diff'd
the relevant source files between gretl versions 2018s and 2018b. It
turns out that 2018b introduced a check on the length of the var->B
coefficient vector (in the function VAR_coeff_matrix_from_VECM in
irfboot.c), and this check wasn't general enough to validate the
var->B that results when an EC coefficient is restricted to equal 0.
The check expected a vector of length 4 but var->B was of length 3,
omitting the coefficient that was forced to zero.
I'm looking into this question: Should the check should be relaxed
under the restriction in question, or should var->B be sized as
expected by the existing check, including an explicit zero entry? I
suspect the latter is better, but once that's resolved a fix will be
applied.
Allin
2:28 p.m.
New subject: bug with fcast
Am 05.01.2022 um 23:30 schrieb Allin Cottrell:
On Tue, 4 Jan 2022, ESTEVEZ NUÑEZ JUAN CARLOS wrote:
> Hi Jack,
> Your code shows any error message with the Windows-32 zip version
> until 2018/05/11, but it fails with 2018/08/11 zip version, and
> following. Maybe some was made meanwhile that causes it.
Thanks for this observation!
I'm working on the bug. Following Juan Carlos's observation I diff'd
the relevant source files between gretl versions 2018s and 2018b. It
turns out that 2018b introduced a check on the length of the var->B
coefficient vector (in the function VAR_coeff_matrix_from_VECM in
irfboot.c), and this check wasn't general enough to validate the
var->B that results when an EC coefficient is restricted to equal 0.
The check expected a vector of length 4 but var->B was of length 3,
omitting the coefficient that was forced to zero.
I'm looking into this question: Should the check should be relaxed
under the restriction in question, or should var->B be sized as
expected by the existing check, including an explicit zero entry? I
suspect the latter is better, but once that's resolved a fix will be
applied.
Hm, I think that depends on the context. For example, if somewhere in
the code the number of var->B elements is used to determine degrees of
freedom, then adding restricted zero elements would imply trouble, no?
In general it sounds as if adjusting the check would be a more
localized, and thus easier, change.
Would the fix also cover the other issue that jack mentioned, that
$system.coeff is wrong?
thanks
sven
5:06 p.m.
New subject: bug with fcast
On Thu, 6 Jan 2022, Sven Schreiber wrote:
Am 05.01.2022 um 23:30 schrieb Allin Cottrell:
> On Tue, 4 Jan 2022, ESTEVEZ NUÑEZ JUAN CARLOS wrote:
>
> > Hi Jack,
> > Your code shows any error message with the Windows-32 zip version
> > until 2018/05/11, but it fails with 2018/08/11 zip version, and
> > following. Maybe some was made meanwhile that causes it.
>
> Thanks for this observation!
>
> I'm working on the bug. Following Juan Carlos's observation I diff'd
> the relevant source files between gretl versions 2018s and 2018b. It
> turns out that 2018b introduced a check on the length of the var->B
> coefficient vector (in the function VAR_coeff_matrix_from_VECM in
> irfboot.c), and this check wasn't general enough to validate the
> var->B that results when an EC coefficient is restricted to equal 0.
> The check expected a vector of length 4 but var->B was of length 3,
> omitting the coefficient that was forced to zero.
>
> I'm looking into this question: Should the check should be relaxed
> under the restriction in question, or should var->B be sized as
> expected by the existing check, including an explicit zero entry? I
> suspect the latter is better, but once that's resolved a fix will be
> applied.
Hm, I think that depends on the context. For example, if somewhere in
the code the number of var->B elements is used to determine degrees of
freedom, then adding restricted zero elements would imply trouble, no?
In general it sounds as if adjusting the check would be a more
localized, and thus easier, change.
Would the fix also cover the other issue that jack mentioned, that
$system.coeff is wrong?
After looking further into this, my diagnosis is that var->B (which
provides $system.coeff) has been too small (too few rows) whenever
alpha is restricted: the EC coefficients have been dropped altogether.
So I think the correct fix is to ensure that the EC coeffs get
inserted, in which case the size check for var->B in irfboot.c can be
retained. If df is then wrong (I don't think so but haven't checked
yet) that should be fixed in its own right.
The presence/absence of the EC coeffs in var->B doesn't actually
matter for "fcast" since in that context we use the VAR representation
of the VECM, but it does matter for the completeness of $system.coeff.
At least that's my current understanding.
Allin
5:28 p.m.
New subject: bug with fcast
Am 06.01.2022 um 18:06 schrieb Allin Cottrell:
On Thu, 6 Jan 2022, Sven Schreiber wrote:
> Would the fix also cover the other issue that jack mentioned, that
> $system.coeff is wrong?
After looking further into this, my diagnosis is that var->B (which
provides $system.coeff) has been too small (too few rows) whenever
alpha is restricted: the EC coefficients have been dropped altogether.
Could you
give a hint where in the code that can be seen? I'm asking
because as I wrote previously I got lost.
So I think the correct fix is to ensure that the EC coeffs get
inserted, in which case the size check for var->B in irfboot.c can be
retained. If df is then wrong (I don't think so but haven't checked
yet) that should be fixed in its own right.
OK
The presence/absence of the EC coeffs in var->B doesn't
actually
matter for "fcast" since in that context we use the VAR representation
of the VECM, but it does matter for the completeness of $system.coeff.
At least that's my current understanding.
That sounds correct, at least the latter part. IIRC, there's a slight
redundancy for VECMs in that the EC coeffs are provided both in $jalpha
and in $coeff / $system.coeff. But it is still important to have them in
$coeff because of the associated $xtxinv information used for
constructing the VCV of the coeffs (especially in the case of
unrestricted alpha). And it is not so trivial to "carve" the EC coeffs
out of $coeff.
But where does gretl get the VAR representation from if not from
VAR_coeff_matrix_from_VECM ? (Which is where the failing check was.)
Thanks
sven
5:40 p.m.
New subject: bug with fcast
On Thu, 6 Jan 2022, Sven Schreiber wrote:
Am 06.01.2022 um 18:06 schrieb Allin Cottrell:
> On Thu, 6 Jan 2022, Sven Schreiber wrote:
> > Would the fix also cover the other issue that jack mentioned, that
> > $system.coeff is wrong?
> After looking further into this, my diagnosis is that var->B (which
> provides $system.coeff) has been too small (too few rows) whenever
> alpha is restricted: the EC coefficients have been dropped altogether.
Could you give a hint where in the code that can be seen? I'm
asking
because as I wrote previously I got lost.
Look at vecm_estimate_full() and vecm_check_size() in
plugin/johansen.c. Before my last push to git we were allocating
var->B with rows equal to the number of coefficients to be estimated
via OLS conditional on beta, which does not include the EC terms when
alpha is restricted. Now I allocate var->B to full size, "shrink" it
for OLS, then re-expand it to insert the ML alpha.
[...]
But where does gretl get the VAR representation from if not from
VAR_coeff_matrix_from_VECM ? (Which is where the failing check was.)
VAR_coeff_matrix_from_VECM does indeed provide the VAR representation,
using the companion matrix and the portion of var->B that refers to
deterministics and/or terms restricted to the cointegration space.
Allin
1094
days inactive
1095
days old
4 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber