8:25 p.m.
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
12:46 p.m.
New subject: [Gretl-users] Trouble in deleting variables
Am 10.12.2010 21:25, schrieb Allin Cottrell:
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.
Well it's not really only cosmetic, see the issue that started this
thread. And this kind of two-book-concept is usually denominated by the
obscure name of a "database" with "keys" :-) The DBMS (database
management system) keeps track of the memory chunks to which the
immutable keys should point.
Anyway, given the current status quo it may well be that it's best to
leave the whole thing as it is. I tend to agree that the user-level
constraints are not a big problem (unless somebody else comes up with
more annoying examples). But if we were to discuss the design as such,
I would argue for a database-like solution without those constraints.
cheers,
sven
2:47 p.m.
New subject: [Gretl-users] Trouble in deleting variables
On Sat, 11 Dec 2010, Sven Schreiber wrote:
Am 10.12.2010 21:25, schrieb Allin Cottrell:
>
> 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.
Well it's not really only cosmetic, see the issue that started this
thread.
I would count that issue as basically cosmetic. Gretl session
files are compressed and disk space is cheap, so having some
series stored in a session file that are not strictly necessary
doesn't strike me as a serious problem.
And this kind of two-book-concept is usually denominated by the
obscure name of a "database" with "keys" :-) The DBMS (database
management system) keeps track of the memory chunks to which the
immutable keys should point.
OK, you're right, this is doable. But what we have at present is a
fast and light system for referencing series, and if we went to
what you describe we'd need to add a DB-access layer to the
back-end of almost every gretl command. In addition it would be
backward-incompatible: any scripts that rely on the current
behavior of series numbering on deletion of variables wouldn't
work any more.
Also note that even at present it's rather easy to construct a
"minimal" gretl session file (i.e. with unused series deleted) via
script. Here's a simple example:
<script>
open data9-7
INCOME = INCOME * POP
list X = INCOME PRICE
list lX = logs(X)
logs QNC
delete STOCK POP WINTER SPRING SUMMER FALL
m1 <- ols l_QNC 0 lX
</script>
Run this, and save the session, and you'll have a file that
contains the saved model plus a selected subset of data9-7. All
you have to do is arrange for the unwanted series to be deleted
before you use higher-numbered series in a saved object.
(As the example illustrates, named lists are robust with respect
to deletion of series.)
Allin
5:09 a.m.
New subject: Plotbars - Presidential Administrations
I've attached two txt files for possible inclusion with plotbars
They contain data on the US presidential terms extracted from
Wikipedia.
Regards
Peter
11:55 a.m.
New subject: Plotbars - Presidential Administrations
Em 22 de dezembro de 2010 Peter <peter(a)tomatoad.com> escreveu:
I've attached two txt files for possible inclusion with plotbars
They contain data on the US presidential terms extracted from
Wikipedia.
This is nice! I'll try to do the same for Brazil ;-)
Best regards,
--
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
5118
days inactive
5132
days old
4 comments
4 participants
participants (4)
-
Allin Cottrell -
Henrique Andrade -
peter -
Sven Schreiber