Re: [Gretl-devel] Midas syntax, small issue
On Wed, 13 Sep 2017, Sven Schreiber wrote:
I don't want to open too many Midas threads, so I'm kind of
hijacking my own: Here's another issue, but this time it looks
like a bug to me.
From what I understand, the polynomial specification
beta-zero-last-lag (type code 2) should give a coefficient weight
of zero for the last lag, hence its name. (The only exception
should be the case when the two hyperparameters are both one,
theta = {1, 1}.)
However, consider these examples:
<hansl>
eval mweights(10, {0,0}, 2)' # gives 0.5 at the end
eval mweights(10, {0.5, 0.5}, 2)' # dito
eval mweights(10, {1.1, 1}, 2)' # gives 0.1194
eval mweights(10, {2, 1}, 2)' # gives 0.2
</hansl>
Am I missing something?
If it's really a bug, does it only affect the mweights() function or does it
spill over into actual midasreg results?
Hmm. I've checked, and our "beta-with-zero-last-lag" weights agree
with those produced by Ghysels' MIDAS Matlab Toolbox and also midasr
(modulo the fact that midasr for some reason makes the weights sum
to the number of hyperparameters rather than to 1.0, as with Matlab
and gretl).
So our calculations seem to be right, but apparently the doc is not
entirely accurate -- an inaccuracy that is inherited from the Matlab
doc. It seems that, besides the {1, 1} case, "pathological"
hyperparameter vectors can give a non-zero last lag. Looking at the
weights implied by your 4 cases above, they are somewhat strange.
{0, 0}: All weights are machine-zero apart from the first and last.
{0.5, 0.5}: All pretty much ~= 0 apart from first and last.
{1.1, 1}: weights increase progressively at longer lags.
{2, 1}: ditto.
My impression is that "sane" values of theta have theta_1 around 1.0
and theta_2 > theta_1 -- and that such vectors will respect the
"zero last lag" condition. Admittedly, this is not explicitly stated
anywhere (that I'm aware of).
Allin