On Tue, 5 Mar 2013, Allin Cottrell wrote:
On Tue, 5 Mar 2013, Riccardo (Jack) Lucchetti wrote:
> On Tue, 5 Mar 2013, Allin Cottrell wrote:
>
>> On Tue, 5 Mar 2013, Andreas Noack Jensen wrote:
>>
>>> I am checking some gretl code against CATS in RATS and using the
>>> australian
>>> dataset. When exporting to csv, the variable iau2 only has three digits
>>> after the dot, but the variable has up to four non zero digits after the
>>> dot in gretl and hence I get different results from the exported data
>>> than
>>> I do in gretl. Is it a bug?
>>
>> Looks like it. I'll take a look at the relevant code shortly.
>
> In the meantime, you can use
>
> set csv_digits 18
>
> and force the number of digits in the csv file.
Hmm, yes, we need to document that.
I was about to, but then I realised that maybe at this point we may want
to revisit this setting to make it more intuitive. My understanding of the
way it works at present is: if csv_digits is n, then see what happens with
n decimal digits after the decimal separator. If for a series the last m
digits are all zeros, then use n-m digits for that variable. So it would
seem that csv_digits is an _upper_ bound. However, if you set it to some
large value (like 18), then machine precision kicks in and the last digits
are not 0 because of numerical noise, so no truncation occurs and you
effectively get n digits after the decimal separator for all variables.
This does not strike me as particularly intuitive. I guess that most users
would interpret a setting like
set cvs_digits 8
as "use 8 digits all the time, come what may". Allin, I imagine you have
a good reason against this, but I fail to see it right now.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------