[R] Number changed weirdly when converting to numeric

[Martin Maechler]

>>>>> J C Nash 
>>>>>     on Sun, 9 Mar 2025 14:19:00 -0400 writes:

    > This may be way off the mark, but is it possible that the ARM machine is using
    > the "new" IEEE-754 arithmetic that does not have 80 bit extended? The standard
    > was changed (in ways to allow non-compliant systems to be compliant) because
    > ARM does not have the hardware registers. There are reasons why this might be
    > sensible, but we need more awareness of the consequences to avoid some of the
    > resulting changes in results. I've had to "fix" things that weren't broken because
    > M1 and later Macs gave different outputs, actually not in my code but in vignettes
    > where I compared to other packages.

Yes, indeed; very much the same here, thank you, John.
and yes, the consequences I've seen (in the R world) have been
considerably larger than many would have expected.

OTOH, I agree (with people saying) that I (and others) had
become too much dependent on assuming quite specific floating
point arithmetic behavior (basically something like "x86_64 everywhere")
which has not been a good long term behaviour.

and "yes" (nr. 3): I tell everybody that indeed, the speed of
the M{1,2,3,4,..} chips is amazing and beating all competition
at the moment, *BUT* the cost is decreased accuracy in amazingly
many situations.

Martin

    > Cheers,

    > John Nash
    > (who actually was part of 1985 IEEE 754 committee, though a VERY minor player)

    > On 2025-03-09 14:06, Stephanie Evert wrote:
    >> For once, that doesn't seem to be the issue here. The bug only seems to happen on arm64 and doesn't reproduce on x86_64 hardware.
    >> 
    >>> x <- as.numeric("-177253333.333333343267441")
    >>> sprintf("%.15f", x)
    >> [1] "-177253333.333333373069763"
    >> 
    >> This is the number adjacent to -177253333.333333343267441 in IEEE 754.
    >> 
    >>> writeBin(x, raw(8))
    >> [1] ac aa aa aa 57 21 a5 c1
    >> 
    >> If you look at the hexadecimal representation, the least significant bit appears to be off by one: the first byte should be 0xAB rather than 0xAC (according to online calculators such as https://numeral-systems.com/ieee-754-converter/).
    >> 
    >> Seems that decimal-to-float conversion has a bug on arm64. Note that I get the same result with
    >> 
    >>> x <- -177253333.333333343267441
    >> 
    >> so it's not specific to as.numeric().
    >> 
    >> Best,
    >> Stephanie
    >> 
    >> 
    >> 
    >> 
    >>> On 9 Mar 2025, at 18:46, Jeff Newmiller via R-help <r-help using r-project.org> wrote:
    >>> 
    >>> https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
    >>> 
    >>> https://0.30000000000000004.com/
    >>> 
    >>> On March 9, 2025 10:12:47 AM PDT, Christofer Bogaso <bogaso.christofer using gmail.com> wrote:
    >>>> Hi,
    >>>> 
    >>>> I have below simple conversion
    >>>> 
    >>>>> sprintf("%0.15f", as.numeric("-177253333.333333343267441"))
    >>>> 
    >>>> [1] "-177253333.333333373069763"
    >>>> 
    >>>> I could not figure out why the input and output is different?
    >>>> 
    >>>> Clearly this conversion is incorrect. Is there any way to convert to
    >>>> numerical properly?
    >>>> 
    >>>>> sessionInfo()
    >>>> 
    >>>> R version 4.4.0 (2024-04-24)
    >>>> 
    >>>> Platform: aarch64-apple-darwin20
    >>>> 
    >>>> Running under: macOS 15.3.1
    >>>> 
    >>>> 
    >>>> Matrix products: default
    >>>> 
    >>>> BLAS:   /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRblas.0.dylib
    >>>> 
    >>>> LAPACK: /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib;
    >>>> LAPACK version 3.12.0
    >>>> 
    >>>> 
    >>>> locale:
    >>>> 
    >>>> [1] C/UTF-8/C/C/C/C
    >>>> 
    >>>> 
    >>>> time zone: Asia
    >>>> 
    >>>> tzcode source: internal
    >>>> 
    >>>> 
    >>>> attached base packages:
    >>>> 
    >>>> [1] stats     graphics  grDevices utils     datasets  methods   base
    >>>> 
    >>>> 
    >>>> loaded via a namespace (and not attached):
    >>>> 
    >>>> [1] compiler_4.4.0
    >>>> 
    >>>> ______________________________________________
    >>>> R-help using r-project.org 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.
    >>> 
    >>> -- 
    >>> Sent from my phone. Please excuse my brevity.
    >>> 
    >>> ______________________________________________
    >>> R-help using r-project.org 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.
    >> 
    >> 
    >> [[alternative HTML version deleted]]
    >> 
    >> ______________________________________________
    >> R-help using r-project.org 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.

    > ______________________________________________
    > R-help using r-project.org 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.