Re: [Gretl-devel] Bug (?) in hi-freq lag counting of midas
On Sun, 9 Jul 2017, Sven Schreiber wrote:
I think a midasreg with a 'mdsl' term may get the included
lags
wrong in the information that is printed in the output.
For example, as a benchmark I have the following (shortened) line:
midasreg dep ... ; ... mds(dO, 2,3 , 2, theta)
So my high-frequency lags of dO go from 2 to 3, and indeed gretl tells
me just that in the output:
MIDAS list dO, high-frequency lags 2 to 3
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
Fine -- I know there are numerical problems here but that's not the
issue right now. I can get the same result by defining a lag list dOL
with hi-freq lags 2 to 3, and then using mdsl:
midasreg dep...; ... mdsl(dOL, 2, theta)
This produces the same result numerically which makes me confident that
I defined the dOL list correctly; however, gretl no tells me the lags
would be from 1 to 2 instead:
MIDAS list dOL, high-frequency lags 1 to 2
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
I now see what's happening here. We get the lag reporting right in the
mdsl() case if the span of the high frequency lags encompasses at
least one full low-frequency period. In the quarterly/monthly case
that would mean at least 3 monthly lags; with just 2 monthly lags
included our current heuristic fails.
So we need a more robust heuristic. But in the Q/M case it's kinda
strange to include less than 3 lags: that invites numerical problems
since the optimizer doesn't have enough lags to figure out the shape
of the decay function.
Allin