>>>>> 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@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.christo...@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@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@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@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@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@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.
