On Fri, 10 Dec 2010, Sven Schreiber wrote:
Am 10.12.2010 19:41, schrieb Henrique Andrade:
> Em 10 de dezembro de 2010 Allin Cottrell <cottrell(a)wfu.edu
>
> It happens because if you were to delete those variables this
> would result in the re-numbering of several variables that appear
> as dependent or as regressors in saved models, which would totally
> confuse gretl.
>
> Perhaps the error message should be adjusted in this case: saying
> that the variable is "in use" is not quite accurate. But the
> substantive point is correct: you really can't delete those series
> without destroying your session file.
>
>
> Dear Allin,
>
> In my humble opinion this behavior doesn't look good. Suppose
hm, I think I'm sharing Henrique's view here. I certainly don't want to
confuse gretl (meaning: I understand that this is stuff that cannot be
changed quickly or easily), but in principle I think the external
numbering of variables shouldn't cause these kind of constraints.
Which leads me to ask: why actually do the variables have to be
renumbered after deleting something? Couldn't the numbers be simply
non-contiguous? Alternatively, maybe (in the longer term) there should
be a mapping from an internal immutable id number to the externally
visible numbering of the variables.
The ID number of a series in gretl is simply the 0-based position
of that series in a two-dimensional array of double-precision
values. If a given series is deleted, it's inevitable that
higher-numbered series will be relocated and hence renumbered --
unless we were to permit holes in the dataset, which would be a
programming nightmare.
Neither IMO, does it make any sense to keep two sets of books, one
recording where variables actually are and another for some sort
of cosmetic purpose; the mapping between these two would be an
obvious source of errors, crashes and so on.
The only way that I can see to permit deletion of lower-numbered
series when higher-numbered ones are "in use" is to crawl all over
the session and adjust all references to series by ID number,
wherever they are found (notably in saved models but also
elsewhere). This is doable in principle, but is a likely source of
errors.
Allin