Both atof() and strtod() give the correct result on my M1 MacBook. So it looks
to me like a bug in R_strtod5(), possibly something that requires extended
80-bit precision to get the conversion right.
Doesn't seem to be the fault of the ARM chip, so I'd say it warrants a bug
report.
Perhaps we can learn from SQLite, which has recently put some work into making
decimal / double conversion more reliable IIRC (possibly even triggered by
similar problems on arm64).
https://github.com/sqlite/sqlite/blob/eed4e1d2df599952f191182cf51646de11b110a6/src/util.c#L577
A key difference seems to be that SQLite accumulates the significand in an
uint64_t in order to get 18 or 19 digits of precision before conversion to
double.
Best,
Stephanie
> On 9 Mar 2025, at 19:24, Ben Bolker <[email protected]> wrote:
>
> Out of curiosity, what does atof() do on that platform? What does the
> following C program do on arm64? (I don't know exactly what R does to coerce
> character to double, but this is what I would guess ...)
>
> #include <stdio.h>
> #include <stdlib.h>
> int main(void) {
> const char *str = "-177253333.333333343267441";
> double x = atof(str);
> printf("%0.15f\n", x);
> return 0;
> }
>
> To my surprise, apparently R doesn't use stdlib to convert.
>
> From
> https://github.com/r-devel/r-svn/blob/bb64b28d8cc2e2863eb664e7f83b0a7206b4b1d4/src/main/util.c#L2087C1-L2107:
>
> /* ...
>
> use our own strtod/atof to mitigate effects of setting LC_NUMERIC
>
> Also allows complete control of which non-numeric strings are
> accepted; e.g. glibc allows NANxxxx, macOS NAN(s), this accepts "NA".
>
> ... */
>
> Should this be escalated to r-devel (or r-bugzilla)? Nothing pops out at me
> from the recent NEWS ...
>
[[alternative HTML version deleted]]
______________________________________________
[email protected] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.