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
<jdnew...@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
<stefa...@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@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.
--
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.
______________________________________________
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.
--
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.
______________________________________________
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.
