Christofer Bogaso
2025-Mar-09 21:55 UTC
[R] Number changed weirdly when converting to numeric
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... On Mon, Mar 10, 2025 at 1:01?AM Jeff Newmiller <jdnewmil at 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 at 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 at 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 at 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 at 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 at 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.
Duncan Murdoch
2025-Mar-09 22:31 UTC
[R] Number changed weirdly when converting to numeric
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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.