On Sat, 16 Dec 2006, Sven Schreiber wrote:
Allin Cottrell schrieb:
> On Fri, 15 Dec 2006, Sven Schreiber wrote:
>> * store saves data in ~, even though ~/gretl is activated in prefs
> The notion is that "store" is an "expert" command: the filename
> exactly what you type on the command line, so if it's not an absolute
> path it goes into the present working directory. This should be
> documented, no doubt.
Which (environment?) variable determines that directory then?
PWD, on *nix systems (I don't know about Windows).
Or related to that: How can I find out in a script where the
user directory (which is set in gretl's preferences) is to use
Urgh. Why do you need that? I suppose it could be exported to
the environment if need be, but right now there's no way to do
that, unless perhaps by clever use of the "!" shell command.
(In relation to storing time-series data as text/CSV)
Well gretl isn't entirely consistent here; consider what a
test.csv LRM --csv' gives me for the quarterly Danish example data:
I have two problems with that:
1) Ok, "1974Q1" is a string and thus comes with quotes. But so are
and "LRM", yet they don't have quotes around them.
But they're bound to be interpreted as strings. Quotes are a
2) For annual data you get "'1960" as a spreadsheet
workaround, but for
quarterly you don't get the single quote. Actually, although I
understand your Excel argument for stuff with a ":" in it, I don't
understand why that would be relevant for simple year integers in annual
It wouldn't. There's an accretion of kludges going on here.
All this makes parsing gretl's csv files error-prone IMHO. I
propose to do one of the following two things: Either enclose
_all_ strings in double quotes, and have the
enclosed-but-leading single quote for all date values; (X)OR
remove _all_ quotes, and change the separator ':' to 'M', 'W',
'D' according to the data frequency, in analogy to the 'Q' for
quarterly data. What do you think?
Sounds reasonable. One consideration is the possibility of
"round-tripping". That is, ideally if you export gretl data to
CSV then read them back into gretl, the time-series information
should be preserved. I'm not sure if that's the case at present,
but it's something I've thought of (at least intermittently) when
messing with the exporter/importer code.
>> * gui importing from csv seems to presuppose .csv extension,
>> must use ascii import for csv files with different extension
>> -- is that necessary?
> No, probably not.
Then I would suggest to mimic the behavior of ASCII import, or possibly
merge them anyway, just like in the 'open' command.
One possibility I've had in mind for a while is merging everything
under "open" (scrap the "import" command and associated menu
items). Unfortunately, other issues (such as implementing
Arellano-Bond or fixing the behaviour of sub-sampling commands
within user-defined functions) have got in the way ;-)