[Rd] RFC: hexadecimal constants and decimal points

[Prof Brian Ripley]

On Mon, 18 Apr 2005, Peter Dalgaard wrote:

> Martin Maechler <maechler at 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 at 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