Re: [Gretl-devel] OLS Forecasting
On Wed, 11 Feb 2009, Sven Schreiber wrote:
I wasn't saying that all that internal stuff that you mention
should be changed. I'm just saying that there shouldn't be
strange workarounds like "renaming forbidden" to get a new
feature (like the one that was being discussed, dynamic
forecasts with appropriate confidence intervals).
On the "strange workarounds", see below.
When I said "lag polynomials should be made explicit if you
want
to have some calculations based on them" I meant something like
the following: If a user wants to specify a distributed-lag
model and then do forecasts etc., it must be documented clearly
that she must specify the lags, differences etc. within the
presented model interface (dialog, command options etc.). So if
a user manually creates lagged variables, then gretl somehow
loses track of the relationship between the variables (ok by me,
BTW), and then those manually created variables are added to a
model, the user shouldn't expect gretl to produce correct
forecasts.
The thing is that even if the user operates "within the presented
model interface", the lag information is (currently) _not_ saved
in the model itself (other than, to some degree, with VARs and
VECMs).
The lag selections made by the user are "understood" by gretl at a
certain point, but then they are converted to a "flat" list of
variable index numbers (some of which may happen to refer to lags)
-- because that is what the underlying OLS function deals with.
The lag information is not totally lost, but it is dispersed: the
created lags are marked as such in the dataset, and given a saved
model structure we can reconstitute the lag info (e.g. for
forecasting purposes) by searching for matches. But if the user
takes the step of renaming the "parent" variable for a bunch of
generated lags, the matching won't work any more: the lags become
"orphans", no longer recognizable as lags.
I think that the requirement to specify lags within the model
interface is something that users will understand and accept. Of
course, the OLS interface then would have to be augmented
similar to the VAR interface -- actually, it may be worthwhile
to just tell the users to specify a one-equation VAR with
exogenous variables, no? Really, now that I think of that, that
may be the best solution...
Up till now you needed at least 2 equations in a VAR, but in
today's CVS I've enabled single-equation VARs. That's fair
enough, because who said a vector needs >= 2 elements. But this
won't help with cross-referencing levels and differences, which
was the original trigger for this discussion.
Allin.