[R] Funky calculations

Avi Gross @v|gro@@ @end|ng |rom ver|zon@net
Tue Feb 1 20:07:50 CET 2022


I suspect there are examples, RUI, where the same code can produce different results based on the underlying representation or manipulation of floating point. There are two main versions I typically see using what some call a "float" and a "double" and I suspect at some future point someone will take 256 bits or so to make a "superdouble" that allots so many more bits to the mantissa and exponent components that you can use much larger numbers with many more significant digits. But it is the final digits where imprecision enters and also a number can vary whether you do rounding or truncating at that point. I think in binary, you generally truncate. So if you consider a number like 1/7 that has an infinitely long decimal representation in bases like decimal, but does have repeats, compared to a transcendental number like pi that does not really repeat, you can round it in decimal representation depending on where you are in the sequence when you stop.

.142857142857142857...

If you stop at a 5 or 7 or 8 and back up to the previous digit, you round up. Else you leave the previous result alone.

.1
.14
.143
.1429
etc.

I actually wrote a much longer explanation about a similar concern someone had in another language, Python, that was picked up and published in a new daily and can be found as the second article at the following URL if interested.

https://pyherald.com/articles/02_01_2022/

It starts like this:

Representing Numbers: The Complexity Behind
Mail by Avi Gross , src

Note I did not choose that title nor did I choose the original Subject line I was replying to here: https://mail.python.org/pipermail/python-list/2021-November/904404.html

And, no, I was not asked nor given any opportunity to polish it or fix a spelling error. It was just my fairly usual free-floating posting style like I use here. It doe illustrate that we are not talking about a bug in R and that the proper way to avoid it may include being aware that sometimes a test for near-equality may be needed.

Think of how many people write an endless loop by waiting for an asymptotic sum like adding 1/2 + 1/4 + 1/8 ... and breaking out of the loop only when the sum is exactly equal to 1.0. Not only will it mathematically never happen, unless you consider happening AT infinity to qualify, but the addition using floating point numbers may end at 0.9999999999999999999999 or so and anything added to it will underflow and always be shown as adding 0 thereafter. But looked at properly, this is pretty much the same problem being reported here. So some people create a small epsilon such as 1E-15 ad write code like:

if (abs(myval - expected) < epsilon) ...

This is another way of saying, if I am close enough, we are there.

All computer languages are alike; except where they aren't.


-----Original Message-----
From: Rui Barradas <ruipbarradas using sapo.pt>
To: Nathan Boeger <nboeger using gmail.com>; r-help using r-project.org
Sent: Tue, Feb 1, 2022 12:07 pm
Subject: Re: [R] Funky calculations


Hello,

Like others have said, this is FAQ 7.31. Try

(0.4 + 0.2 + 0 + 0.3 + 0 + 0.1) - 1


on both systems, on one of them it's not zero.

Hope this helps,

Rui Barradas

Às 13:45 de 01/02/2022, Nathan Boeger escreveu:
> Hello,
> 
> I found something strange and maybe I am going nuts but this does not make
> sense:
> 
>>   (0.4 + 0.2 + 0 + 0.3 + 0 + 0.1) > 1
> [1] TRUE
> 
> I tried it on my mac M1 (R v4.1.2) and my Linux box (R v4.0.4). If I use
> other values, it does not work (see below). It seems only that combination,
> granted I did not try them all.
> 
>>   (0.4 + 0.2 + 0 + 0.2 + 0 + 0.2) > 1
> [1] FALSE
> 
> Am I missing something?
> 
> Cheers
> 
> -nb


 



More information about the R-help mailing list