[R] Number changed weirdly when converting to numeric

Mon Mar 10 00:31:41 CET 2025

   I agree with Duncan.  From an abstract point of view it would be 
interesting, and possibly useful, to analyze exactly what is going 
'wrong' (in some sense) with R's built-in string-to-double function in 
this case, and might lead to some marginal improvements.  But if you are 
doing anything but the simplest floating-point operations you will see 
many other unavoidable differences of similar magnitudes across platforms.

    If you feel like taking a deep dive, this is the classic article 
from 1991: https://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf (and 
the corresponding R-centric Stack Overflow post 
https://stackoverflow.com/questions/9508518/why-are-these-numbers-not-equal/ 
)

On 3/9/25 18:31, Duncan Murdoch wrote:
> On 2025-03-09 5:55 p.m., Christofer Bogaso wrote:
>> So, based on the discussion points from the experts here, I understand
>> that this is an ARM specific problem.
>>
>> However, what should I do for a solution?
>>
>> I use ARM+R in my office workstation, so it may not be prudent to me
>> to just say ignore this problem and let Apple's Tim Cook take care of
>> it...
> 
> No, the problem is much deeper than that.  If your work depends on 
> things that are way out in the limit of floating point precision, then 
> your work is unavoidably unstable already.  The easiest way to fix this 
> is to avoid doing anything that depends on the 15th or 16th or higher 
> significant digit of what you are working with.
> 
> If you really need 20 or 30 digit precision, then you can do it in R, 
> but you need to be extra careful with every single calculation you're 
> doing.  Base R calculations won't be good enough.
> 
> Duncan Murdoch
> 
>>
>> On Mon, Mar 10, 2025 at 1:01 AM Jeff Newmiller 
>> <jdnewmil using dcn.davis.ca.us> wrote:
>>>
>>> I now see more clearly what the complaint is.
>>>
>>> That said, you should ALWAYS be prepared for the round trip between 
>>> binary and string forms of floating point to accrue rounding error 
>>> because floating point is intrinsically approximate. While there are 
>>> examples of floating point numbers that can reliably do that round 
>>> trip exactly (e.g. integers shorter than the mantissa), in general 
>>> you should be prepared for such "inexact" results.
>>>
>>> John Nash's point that IEEE754 has been relaxed is reinforcement that 
>>> they want users to be prepared for differences around the least 
>>> significant bits... but the principle is mathematically intrinsic to 
>>> the scope of floating point numbers whether the standard says so or not.
>>>
>>> On March 9, 2025 11:06:17 AM PDT, Stephanie Evert 
>>> <stefanML using collocations.de> 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.
>>>>
>>>
>>> -- 
>>> 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.
> 
> ______________________________________________
> 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.

-- 
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
* E-mail is sent at my convenience; I don't expect replies outside of 
working hours.