On 09.02.2009 21:35, Allin Cottrell wrote:
On Mon, 9 Feb 2009, Allin Cottrell wrote:
> In fact the tracking of lags/differences is by now fairly robust
> (with regard to non-standard naming of the transformed variables,
> for instance). Provided, that is, that the transformations are
> done within gretl...
OK, let me qualify that. When you generate a lag or difference
within gretl, we record (as data associated with the "child"
variable)
* the nature of the transformation
* the lag, if applicable
* the name of the "parent" variable
This means that we don't depend on a lag having a standard name
such as "foo_2" (for parent foo), or a difference being named as
"d_foo". And the child variable can be renamed without
disruption. On the other hand, if the user (a) creates such a
transformation then (b) renames the parent variable, we lose
track of the parent.
An alternative would be to record the ID number of the parent
variable, but it seemed to me that recording the name was more
robust -- because the "parent renaming" manouevre above is clearly
perverse, while deleting temporary variables in such a way as to
renumber the parent is something that could happen "in all
innocence".
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...)
-sven