Home / Questions / 200048
Accepted
Patricio Moracho
Asked: 2020-09-28 08:24:39 +0800 CST 2020-09-28 08:24:39 +0800 CST

What is the proper way to compare floating point numbers?

  • 772

Surely you have already encountered a problem like the following:

> (2.3 - 1.8) == 0.5
[1] FALSE
> sqrt(2)^2 == 2
[1] FALSE

The explanation to the general problem of handling floating point numbers can be found here: Why can't my programs do arithmetic calculations correctly? .

This is not a problem particular to R but to any language that handles floating point numbers.

Now, how can we resolve or handle these "inconsistencies" in the language when making comparisons?

r

1 Answers

  1. Best Answer

    First of all, the simple demonstration of the problem:

    > sprintf("%.60f",2.3 - 1.8)
[1] "0.499999999999999777955395074968691915273666381835937500000000"
> sprintf("%.60f",sqrt(2)^2)
[1] "2.000000000000000444089209850062616169452667236328125000000000"

    We see that in the first case 2.3 - 1.8it is not exactly 0.5and also that sqrt(2)^2it is not exactly 2. It just so happens that, for clarity, R does not display a large number of decimal places by default:

    > 2.3 - 1.8
[1] 0.5

    This problem is not from R, but is inherent to the computational architecture itself (See: Why can't my programs do arithmetic calculations correctly? ), the impossibility of representing certain numbers by floating point. One might think that the problem is representing numbers like 1/3or Pi, but it is not only these, because of binary algebra, even "simpler" decimal numbers cannot be represented exactly, but what is always handled is an approximation:

    > sprintf("%.60f", 0.5) 
[1] "0.500000000000000000000000000000000000000000000000000000000000"

> sprintf("%.60f", .1) # 0.1 se maneja como una aproximación
[1] "0.100000000000000005551115123125782702118158340454101562500000"

    Obviously only the most significant decimals are seen, we can see up to how many significant digits will be taken with getOption("digits")now if we modify this:

    > options(digits=22) 
> 2.3 - 1.8
[1] 0.49999999999999978

    We clearly notice where we have the problem. How do we resolve this inconsistency?

    Comparisons (equality)

    One of the main problems, as we have already seen, is to compare two numbers where at least one is the product of an operation with floating point values. The natural way to solve it is by using the all.equal()y function combined withisTRUE()

    > isTRUE(all.equal(2.3 - 1.8,0.5))
[1] TRUE

    This is used to treat scalars, or being consistent with the language, vectors with a single element, however for vectors with several elements, the previous solution must be "vectorized", for example:

    > a <- c(0.1+0.05, 1-0.1-0.1-0.1, 0.3/0.1, 0.1+0.1)
> b <- c(0.15,     0.7,           3,       0.15)
# Ya sabemos que la igualdad habitual no funcionará
> a==b                          
[1] FALSE FALSE FALSE FALSE

# Pero tampoco nos sirve all.equal() 
> isTRUE(all.equal(a,b))
[1] FALSE

# La alternativa es vectorizar all.equal() usando mapply()
> mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
[1]  TRUE  TRUE  TRUE FALSE

> # O mucho mejor creando una función ad-hoc
> elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})
 
> elementwise.all.equal(a, b)
[1]  TRUE  TRUE  TRUE FALSE

    Note: In case of using dplyrwe havenear()

    > library(tidyverse)
> near(a,b)
[1]  TRUE  TRUE  TRUE FALSE

    Other comparisons

    For the rest of the comparisons, we must attack the problem in another way. This would be the problem:

    > v <- c(2.3 - 1.8, 0.1 + 0.4, sqrt(0.5)^2)
> v 
[1] 0.5 0.5 0.5

> unique(v)
[1] 0.5 0.5 0.5
> v > 0.5
[1] FALSE FALSE  TRUE

    Here what we can do is use zapsmall()what is nothing more than a "wrapper" around a round()to remove unnecessary digits:

    > unique(zapsmall(v, digits=2))
[1] 0.5
> zapsmall(v, digits=2) > 0.5
[1] FALSE FALSE FALSE

    Sources:

    • 4