Re: [Gretl-devel] OLS Forecasting
On 10.02.2009 04:24, Allin Cottrell wrote:
On Mon, 9 Feb 2009, Sven Schreiber wrote:
> On 09.02.2009 21:35, Allin Cottrell wrote:
>> Thinks: we could ban renaming of variables that have parent status
>> -- maybe not a bad idea.
>>
> Hey hey hey -- it's still a free country, isn't it?
>
> Seriously, I don't think that the approach of behind-the-scenes,
> trying to be smarter than the user will work. IMHO if somebody
> wants to have forecast errors based on lag polynomials, then
> these polynomials should be made explicit. Which brings to mind
> the lag specification dialogs in the VAR case for example. To me
> it seems that something like that would be needed for
> forecasting in the single-equation case. (It also reminds me of
> PcGive again, but that's not a bad thing, because they get the
> dynamic stuff right...)
[Warning: long discursive reply!]
...
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).
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.
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...
cheers,
sven