>>>>> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
>>>>> on Sun, 17 Apr 2005 12:38:10 +0100 (BST) writes:
BDR> These are some points stimulated by reading about C history (and
BDR> related in their implementation).
<.....>
BDR> 2) R does not have integer constants. It would be
BDR> convenient if it did, and I can see no difficulty in
BDR> allowing the same conversions when parsing as when
BDR> coercing. This would have the side effect that 100
BDR> would be integer (but the coercion rules would come
BDR> into play) but 200000000000000000 would be double. And
BDR> x <- 0xce80 would be valid.
Hmm, I'm not sure if this (parser change, mainly) is worth the
potential problems. Of course you (Brian) know better than
anyone here that, when that change was implemented for S-plus, I think
Mathsoft (the predecessor of 'Insightful') did also change all
their legacy S code and translate all '<n>' to '<n>.' just in
order to make sure that things stayed back compatible.
And, IIRC, they recommended users to do so similarly with their
own S source files. I had found this extremely ugly at the time,
but it was mandated by the fact they didn't want to break
existing code which in some places did assume that e.g. '0' was
a double but became an integer in the new version of S-plus
{and e.g., as.double(.) became absolutely mandated before passing
things to C --- of course, using as.double(.) ``everywhere''
before passing to C has been recommended for a long time which
didn't prevent people to rely on the current behavior (in R) that
almost all numbers are double}.
We (or rather the less sophisticated members of the R community)
may get into similar problems when, e.g.,
matrix(0, 3,4) suddenly produces an integer matrix instead of a
double precision one.
BDR> 3) We do allow setting LC_NUMERIC, but it partially breaks R if the
BDR> decimal point is not ".". (I know of no locale in which it is not "."
or
BDR> ",", and we cannot allow "," as part of numeric constants when
parsing.)
BDR> E.g.:
>> Sys.setlocale("LC_NUMERIC", "fr_FR")
BDR> [1] "fr_FR"
BDR> Warning message:
BDR> setting 'LC_NUMERIC' may cause R to function strangely in:
BDR> setlocale(category, locale)
>> x <- 3.12
>> x
BDR> [1] 3
>> as.numeric("3,12")
BDR> [1] 3,12
>> as.numeric("3.12")
BDR> [1] NA
BDR> Warning message:
BDR> NAs introduced by coercion
BDR> We could do better by insisting that "." was the decimal point in all
BDR> interval conversions _to_ numeric. Then the effect of setting
LC_NUMERIC
BDR> would primarily be on conversions _from_ numeric, especially printing
and
BDR> graphical output. (One issue would be what to do with scan(), which
has a
BDR> `dec' argument but is implemented assuming LC_NUMERIC=C. I would hope
to
BDR> continue to have `dec' but perhaps with a locale-dependent default.)
The
BDR> resulting asymmetry (R would not be able to parse its own output)
would be
BDR> unhappy, but seems inevitable. (This could be implemented easily by
having
BDR> a `dec' arg to EncodeReal and EncodeComplex, and using LC_NUMERIC to
BDR> control that 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.
Martin Maechler
ETH Zurich
BDR> All of these could be implemented by customized versions of
BDR> strtod/strtol.
BDR> --
BDR> Brian D. Ripley, [EMAIL PROTECTED]
BDR> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
BDR> University of Oxford, Tel: +44 1865 272861 (self)
BDR> 1 South Parks Road, +44 1865 272866 (PA)
BDR> Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
