Re: [Gretl-devel] crash when trying Midas forecasting
On Fri, 6 Oct 2017, Sven Schreiber wrote:
Am 06.10.2017 um 19:50 schrieb Allin Cottrell:
> On Fri, 6 Oct 2017, Sven Schreiber wrote:
>> snapshot. I suspect it has to do with using several Midas terms for
>> forecasting -- I vaguely seem to remember now that it isn't supported yet,
>> and sometimes I just get an error message. (Although the message "missing
>> values encountered" seems misleading.)
>
> It's supposed to be supported, though it hasn't been tested much and I
> wouldn't really expect it to work well (excessive collinearity?).
Well the pure UMidas variant works, so I don't see why the problem should be
so severe as to result in failure with the Almon spec.
Actually here's a reproducible example for the other error I'm getting
("found missing values"):
<hansl>
open gdp_midas.gdt
list H1 = ld_payems_m?
list H2 = ld_indpro_m?
list L1 = hflags(1, 5, H1)
list L2 = hflags(1, 5, H2)
smpl +0 -3
midasreg ld_qgdp const ld_qgdp(-1) ; \
mdsl(L1, "nealmon") mdsl(L2, "nealmon")
fcast ($t2+1) ($t2+2) --static
</hansl>
The crash you reported in a prior posting was just a case of simple
oversight (with regard to the printing of midasreg results), easily
fixed by (pretty much) a one-liner in the underlying code.
This, however, is more substantive: at present we're not saving
enough information on a midasreg model to generate a forecast, when
the model comprises more than one mds() or mdsl() term. I need to
think a bit about how best to arrange that.
BTW, when I write "fcast ($t2 + 1) ($t2 + 2)" with some
blanks
instead, I get a different (unrelated, I think) error.
OK, we'll get to that later. But I think it may have been a mistake
to allow arbitrary expressions for the start and end of the forecast
range in the "fcast" command. We'd have a better chance of avoiding
errors if we insisted that these limits be (a) integer observation
numbers in numerical form, (b) the names of existing scalar
variables containing such values, or (c) observation strings such as
"2010:4".
But then, maybe if we fix the primary problem the secondary one will
go away.
Allin