4:15 p.m.
Hi,
I repeatedly find myself looking in the built-in dataset collection to
open a dataset with a certain structure (e.g. for testing, or for
teaching). I find it hard to locate for example a panel dataset with T >
N. Couldn't that kind of information be displayed in additional columns?
(So far I see only "File" and "Summary" there.)
thanks,
sven
8:57 p.m.
On Wed, 27 Sep 2017, Sven Schreiber wrote:
Hi,
I repeatedly find myself looking in the built-in dataset collection to open a
dataset with a certain structure (e.g. for testing, or for teaching). I find
it hard to locate for example a panel dataset with T > N. Couldn't that kind
of information be displayed in additional columns? (So far I see only "File"
and "Summary" there.)
I can see a case for a simple additional column, say "dimension",
which could have, for example, "n = 1200" for a cross-sectional
dataset, "T = 96" for time-series, or "N = 20, T = 30" for a panel.
Here's a fairly simple rainy-day task for somebody: go through the
supplied data files (maybe in the first instance just the ones under
the "Gretl" tab) and compose a little text file on the same format
as the existing "descriptions" file, so for instance:
"abdata","N = 140, T = 9"
"anscombe","n = 11"
"arma","T = 624"
...
If anyone does that, I'll be happy to arrange for it to be picked up
in the same way as the current "descriptions" file and displayed in
the GUI.
I'm aware that we _could_ read that info automatically from the gdt
files, but in the interest of responsiveness I think I'd rather not
(gunzip and) parse a bunch of XML files on the user's accessing a
tab in the data browser -- though I suppose that might be worth the
experiment (how long does it really take?). Downside for me: I would
have to code that experiment!
Allin
4:56 p.m.
Am 27.09.2017 um 22:57 schrieb Allin Cottrell:
I can see a case for a simple additional column, say
"dimension", which
could have, for example, "n = 1200" for a cross-sectional dataset, "T =
96" for time-series, or "N = 20, T = 30" for a panel.
Here's a fairly simple rainy-day task for somebody: go through the
supplied data files (maybe in the first instance just the ones under the
"Gretl" tab) and compose a little text file on the same format as the
existing "descriptions" file, so for instance:
"abdata","N = 140, T = 9"
I think it should be possible to put together a hansl script for that.
I'll try (soon; everybody is welcome to beat me to it).
I'm aware that we _could_ read that info automatically from the
gdt
files, but in the interest of responsiveness I think I'd rather not
(gunzip and) parse a bunch of XML files on the user's accessing a tab in
the data browser -- though I suppose that might be worth the experiment
(how long does it really take?). Downside for me: I would have to code
that experiment!
I agree that it's enough as a one-time prepared meta info set at release
time, not on-the-fly.
cheers,
sven
8:46 a.m.
Am 29.09.2017 um 18:56 schrieb Sven Schreiber:
I think it should be possible to put together a hansl script for
that.
I'll try (soon; everybody is welcome to beat me to it).
I have started an attempt, attached, but: CAUTION, this produces a crash
for me (with the latest Windows snapshot which I've just downloaded).
The crash doesn't seem to happen every time, but with a freshly started
gretl instance just now it did. When there's no crash, there seems to
happen some weird over-/underflow error in the N variable (which by
construction should actually be an integer).
thanks,
sven
9:51 a.m.
Am 30.09.2017 um 10:46 schrieb Sven Schreiber:
The crash doesn't seem to happen every time, but with a freshly
started
gretl instance just now it did. When there's no crash, there seems to
happen some weird over-/underflow error in the N variable (which by
construction should actually be an integer).
I can confirm the crash here on ubuntu using a 1-week old git-version.
It happens after re-running the script a couple of times.
Artur
11:58 p.m.
On Sat, 30 Sep 2017, Sven Schreiber wrote:
Am 29.09.2017 um 18:56 schrieb Sven Schreiber:
> I think it should be possible to put together a hansl script for
> that. I'll try (soon; everybody is welcome to beat me to it).
I have started an attempt, attached, but: CAUTION, this produces a
crash for me (with the latest Windows snapshot which I've just
downloaded).
The crash doesn't seem to happen every time, but with a freshly
started gretl instance just now it did. When there's no crash,
there seems to happen some weird over-/underflow error in the N
variable (which by construction should actually be an integer).
Thanks for both the idea and the crash report.
The crash was due to a remaining window of vulnerability created by
our acceptance of the "open" command in loops (something that was
was disallowed until relatively recently). I've now closed that
window in git, so your script should now run OK.
However, the task that your script addresses is easier than you make
it, due to the presence of the $datatype accessor. Given an array of
datafile names "fnames", the following will suffice:
<hansl>
string out = ""
loop i=1..nelem(fnames) --quiet
string tempstr = fnames[i]
printf "Opening %s\n", tempstr
catch open @tempstr --preserve --quiet
if $error
printf "Couldn't open %s\n", tempstr
break
endif
if $datatype == 1
# cross section
out ~= sprintf("\"%s\",\"n = %d\"\n", tempstr, $nobs)
elif $datatype == 2
# time series
out ~= sprintf("\"%s\",\"T = %d\"\n", tempstr, $nobs)
elif $datatype == 3
# panel
N = max($obsmajor)
T = max($obsminor)
out ~= sprintf("\"%s\",\"N = %d, T = %d\"\n", tempstr,
N, T)
else
# weird error
printf "Got no recognized data!?"
break
endif
endloop
print out
</hansl>
Note also that you can't use "temp" as a string (filename) in such a
script without generating confusion, since at least one of the
packaged datafiles contains a series named "temp".
Allin
2:38 p.m.
Am 01.10.2017 um 01:58 schrieb Allin Cottrell:
On Sat, 30 Sep 2017, Sven Schreiber wrote:
However, the task that your script addresses is easier than you make it,
due to the presence of the $datatype accessor.
You're absolutely right -- I had even looked at the list of $-accessors
but didn't guess that $datatype meant what it means.
Note also that you can't use "temp" as a string
(filename) in such a
script without generating confusion, since at least one of the packaged
datafiles contains a series named "temp".
Ah, that's where the other strange error messages came from!
thanks,
sven
3:36 p.m.
Am 02.10.2017 um 16:38 schrieb Sven Schreiber:
You're absolutely right -- I had even looked at the list of
$-accessors
but didn't guess that $datatype meant what it means.
Using the $datatype variant this works fine now -- I guess you don't
need the text file explicitly anymore, or should I send it?
There's only one problem with the datafile data7-25 ("Congressional
Elections..."), because it cannot be found, also with a manual GUI-based
attempt. Is it missing in the install, or is the dataset list entry
obsolete?
thanks,
sven
5:39 p.m.
On Wed, 4 Oct 2017, Sven Schreiber wrote:
Am 02.10.2017 um 16:38 schrieb Sven Schreiber:
> You're absolutely right -- I had even looked at the list of $-accessors but
> didn't guess that $datatype meant what it means.
Using the $datatype variant this works fine now -- I guess you don't need the
text file explicitly anymore, or should I send it?
That's OK, I can construct using your idea.
There's only one problem with the datafile data7-25
("Congressional
Elections..."), because it cannot be found, also with a manual GUI-based
attempt. Is it missing in the install, or is the dataset list entry obsolete?
Hmm, I can't find that dataset anywhere; I guess it should be removed
from the listing.
Allin
2408
days inactive
2415
days old
8 comments
3 participants
participants (3)
-
Allin Cottrell -
Artur Tarassow -
Sven Schreiber