[Gretl-devel] Re: 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