> So in this case, the different results are not due to the architecture (M1
> aka ARM64) but to the system/implementation.
I would say that your results demonstrate that R number parsing code relies on
higher-than double precision to perform correct number parsing. Extended
precision is not gu
The difference between macOS 12.4 and Debian 11 (Docker, virtualization
framework) running on a MacBook Pro (M1 Max).
-> `.Machine$sizeof.longdouble` on macOS returns 8 whereas on Debian 11 it
returns 16.
macOS 12.4 on MacBook Pro (M1 Max):
``` r
.Machine
#> $double.eps
#> [1] 2.220446e-16
#>
#
I don’t think there is any guarantee that unrepresentable numbers are parsed
into defined patterns, because printing is done by the OS while parsing is done
by R. The way R parses decimal numbers[1] is simply by using the obvious res =
res * 10 + digit and it can be easily checked that for doubl
On Sun, 10 Jul 2022 at 16:28, GILLIBERT, Andre
wrote:
>
> > No, that is how computers work (with floating point numbers).
>
>
> The fact that not all values are representable by floating point does not
> mean that outputing a number with maximum accuracy, then reading it back,
> should yield a d
