[Gretl-users] 'store' issues

[Allin Cottrell]

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 used is
>> 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 
> that value?

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 'store
> test.csv LRM --csv' gives me for the quarterly Danish example data:
>
> obs,LRM
> "1974Q1",11.63255023
> "1974Q2",11.60415248 ...

> I have two problems with that:
> 1) Ok, "1974Q1" is a string and thus comes with quotes. But so are "obs"
> and "LRM", yet they don't have quotes around them.

But they're bound to be interpreted as strings.  Quotes are a 
no-op.

> 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
> data.

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 ;-)

Allin.