Re: [Gretl-devel] Bug (?) in hi-freq lag counting of midas
On Mon, 10 Jul 2017, Sven Schreiber wrote:
Am 10.07.2017 um 21:32 schrieb Allin Cottrell:
> On Mon, 10 Jul 2017, Sven Schreiber wrote:
>
>> [...] I think there are special cases (of Almon?) where you can reduce the
>> whole thing to a single parameter? So it's not always absurd to have only
>> two or even one lag.
>
> I don't mean to drive this into the ground, but on reflection including
> only 2 lags with any of the MIDAS hyperparameterizations is definitely the
> wrong thing to do. If you want only two lags, use the unrestricted
> (U-MIDAS) specification. Otherwise you're in effect forcing the algorithm
> to estimate a smooth decay function with only two data-points, and this
> cannot go well.
Yeah, it's all a question of identification, and I'm definitely a friend of
U-Midas. But if only for pedagogical purposes, it's sometimes interesting to
compare the U-Midas results with low-lag hyperparametrizations, as long as
they're theoretically identified.
Ghysels argues that while U-MIDAS will fit better in-sample (by
construction, if n(lags) > n(hyperparameters)) it generally does
worse at forecasting out of sample. I can confirm that from my
experiments on US quarterly/monthly data. IMO, setting n(lags) =
n(hyperparameters) does not really produce a meaningful comparison
between U-MIDAS and the functional-form approaches; the latter need
to be allowed sufficient lags to do their thing.
Conversely, it _would_ be meaningful to compare low-order U-MIDAS
with beta or exponential Almon with a comparable number of
parameters (not lags).
Allin