[R] Number changed weirdly when converting to numeric

[Stephanie Evert]

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 <bbolker using gmail.com> 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]]