Am 07.10.2017 um 02:12 schrieb Allin Cottrell:
On Fri, 6 Oct 2017, Sven Schreiber wrote:
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.
Really? When I look at $model.midas_info and its member bundles
(here: midas_info[1] and midas_info[2], in general up to the number of
Midas terms) it seems there's everything one needs, in combination with
$model.coeff.
It would probably be a bit tedious but apparently doable even from the
hansl side, with the help of mlincomb() -- just talking about point
forecasts here now.
Do you want me to attempt a prototype?
> 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".
Well, maybe, in principle I wouldn't mind that restriction too much.
However, with the observation strings I recall having some problems in
the past. And there's the ambiguity about annual data year versus obs
numbers. So what really seems important to support is the use of
obsnum() expressions right in the fcast command, and perhaps also
obslabel(). Otherwise it would feel a bit lame, to be honest.
thanks,
sven