RFC: hexadecimal constants and decimal points

Mon, Apr 18, 2005 12:08 PM

On Mon, 18 Apr 2005, Peter Dalgaard wrote:

Martin Maechler <maechler@stat.math.ethz.ch> writes:

    BDR> We could do better by insisting that "." was the decimal
    BDR> point in all interval conversions _to_ numeric. Then the
    BDR> effect of setting LC_NUMERIC would primarily be on
    BDR> conversions _from_ numeric, especially printing and
    BDR> graphical output. (One issue would be what to do with
    BDR> scan(), which has a `dec' argument but is implemented
    BDR> assuming LC_NUMERIC=C. I would hope to continue to have
    BDR> `dec' but perhaps with a locale-dependent default.) The
    BDR> resulting asymmetry (R would not be able to parse its own
    BDR> output) would be unhappy, but seems inevitable. (This could
    BDR> be implemented easily by having a `dec' arg to EncodeReal
    BDR> and EncodeComplex, and using LC_NUMERIC to control that
    BDR> rather than actually setting the local category. For
    BDR> example, deparsing needs to be done in LC_NUMERIC=C.)

Yes, I like this quite a bit:

 -  Only allow "." as decimal point in conversions to numeric.

 -  Allowing "," (or other locale settings if there are) for
    conversions _from_ numeric will be very attractive to some
    (not to me) and will make the use of R's ``reporting
    facility' much more natural to them.

  That the asymmetry is bit unhappy -- and that will be a good reason
  to advocate (to the user community) that using "," for decimal
  point may be a bad idea in general.

Could I suggest that we tread very carefully here? This issue has
caused several trip-ups historically:

- The locale-dependent "comma-separated variables" format, in some
 cases not separated by commas. And it seems that you can still get
 Excel files that use comma both for separation and as decimal point
 (I thought that problem disappeared with early versions of Paradox,
 but apparently not, according to a resent query on r-help).

- Exports from SAS as a text file cannot be read by SPSS and vice
 versa.

etc. Quite possibly, the "computer world" missed the opportunity to
agree on an international standard (what's the big deal with using
commas anyway?). As it is we probably have to adjust to it, but we
have to distinguish very carefully between reports, code, and data,
and choose appropriate conventions for each case.

I was treading _very_ carefully.  Nowhere did I suggest altering any of
write.table and friends.  I did not even suggest altering read.table.
I tentatively suggested the default in scan() might be locale-specific,
but was otherwise leaving import/export completely alone.

The aim is to allow people to have commas in printed output and graph 
labels if they want.  Note, nothing would be done unless people explicitly 
did something like Sys.setlocale("LC_MISSING", "fr_FR") so this would not 
affect naive users in any way.

Brian

Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

RFC: hexadecimal constants and decimal points

Thread (9 messages)