Both atof() and strtod() give the correct result on my M1 MacBook. So it looks
to me like a bug in R_strtod5(), possibly something that requires extended
80-bit precision to get the conversion right.
Doesn't seem to be the fault of the ARM chip, so I'd say it warrants a bug
report.
Perhaps we
> 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
lf Of Christofer Bogaso
Sent: Sunday, March 9, 2025 1:13 PM
To: r-help
Subject: [R] Number changed weirdly when converting to numeric
[External Email]
Hi,
I have below simple conversion
> sprintf("%0.15f", as.numeric("-17725.33343267441"))
[1] "-17725.
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 bu
As has now been explained, there is a lot going on under the hood
here. I would just note that the Rmpfr package can do arbitrary
precision arithmetic; and so can the Ryacas package, which extends
these capabilities to e.g. arbitrary precision linear algebra.
(I am just parroting what I found via
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 p
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...
Out of curiosity, what does atof() do on that platform? What does
the following C program do on arm64? (I don't know exactly what R does
to coerce character to double, but this is what I would guess ...)
#include
#include
int main(void) {
const char *str = "-17725.33343267441";
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 r
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
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("-17725.33343267441")
> sprintf("%.15f", x)
[1] "-17725.33373069763"
This is the number adjacent to -17725.33343267441 in IE
https://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f
https://0.30004.com/
On March 9, 2025 10:12:47 AM PDT, Christofer Bogaso
wrote:
>Hi,
>
>I have below simple conversion
>
>> sprintf("%0.15f", as.numeric("-17725.33343267441"))
Hi,
I have below simple conversion
> sprintf("%0.15f", as.numeric("-17725.33343267441"))
[1] "-17725.33373069763"
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?
> sessionInf
I can't reproduce this locally.
sprintf("%0.15f", as.numeric("-17725.33343267441"))
[1] "-17725.33343267441"
R Under development (unstable) (2025-03-08 r87909)
Platform: x86_64-pc-linux-gnu
Running under: Ubuntu 24.04.2 LTS
On 3/9/25 13:12, Christofer Bogaso wrote:
Hi,
I h
14 matches
Mail list logo
