Re: [Gretl-devel] Number of digits in export
On Wed, 6 Mar 2013, Riccardo (Jack) Lucchetti wrote:
[re. the "set" variable named "csv_digits", which is not
currently documented]
I was about to [document it], 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.
Here's what the _intent_ is (we need to do some more checking
to see if it's properly implemented, but I think it is):
1) If you don't set "csv_digits", then gretl prints CSV values
using an algorithm designed to preserve precision to a
reasonable degree while producing a reasonably elegant and
easily readable output file (details below).
2) If you set a value for "csv_digits" then gretl doesn't try
to do anything clever, it just prints CSV values to the
specified number of significant digits (not decimal places).
Note that we use "%g" conversion, so trailing zeros are
dropped.
Details on the default algorithm: We check each series to
determine if it can be printed in "%f" format, with a
reasonably small uniform number of decimal places, without
loss of precision.[*] This is often the case for "primary"
data (as opposed to logs and such). If so, do it; if not,
print to 12 significant figures using "%g" format. The 12 here
is somewhat arbitrary, but the idea is to preserve reasonable
precision while avoiding printing "trailing junk" that is just
an artifact of the finite precision of 64-bit floating point
numbers. (You can see such junk if you open australia.gdt, do
"set csv digits 18", store as CSV, and open the CSV file in a
text editor.)
[*] The bug that Andreas exposed was a flaw in this procedure,
now fixed.
Allin