Why are these numbers not equal?
up vote
227
down vote
favorite
The following code is obviously wrong. What's the problem?
i <- 0.1
i <- i + 0.05
i
## [1] 0.15
if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
## i does not equal 0.15
r floating-point floating-accuracy r-faq
add a comment |
up vote
227
down vote
favorite
The following code is obviously wrong. What's the problem?
i <- 0.1
i <- i + 0.05
i
## [1] 0.15
if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
## i does not equal 0.15
r floating-point floating-accuracy r-faq
5
See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.
– Aaron
Mar 1 '12 at 2:10
add a comment |
up vote
227
down vote
favorite
up vote
227
down vote
favorite
The following code is obviously wrong. What's the problem?
i <- 0.1
i <- i + 0.05
i
## [1] 0.15
if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
## i does not equal 0.15
r floating-point floating-accuracy r-faq
The following code is obviously wrong. What's the problem?
i <- 0.1
i <- i + 0.05
i
## [1] 0.15
if(i==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
## i does not equal 0.15
r floating-point floating-accuracy r-faq
r floating-point floating-accuracy r-faq
edited May 30 at 19:56
Jaap
54k20116128
54k20116128
asked Feb 29 '12 at 23:46
dplanet
1,99082140
1,99082140
5
See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.
– Aaron
Mar 1 '12 at 2:10
add a comment |
5
See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.
– Aaron
Mar 1 '12 at 2:10
5
5
See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.
– Aaron
Mar 1 '12 at 2:10
See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.
– Aaron
Mar 1 '12 at 2:10
add a comment |
4 Answers
4
active
oldest
votes
up vote
303
down vote
accepted
General (language agnostic) reason
Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.
This is a well known limitation of computer arithmetic and is discussed in several places:
- The R FAQ has question devoted to it: R FAQ 7.31
The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)- David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)
- The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic
0.30000000000000004.com compares floating point arithmetic across programming languages- Several Stack Overflow questions including
- Why Are Floating Point Numbers Inaccurate?
- Why can't decimal numbers be represented exactly in binary?
- Is floating point math broken?
Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)
Comparing scalars
The standard solution to this in R
is not to use ==
, but rather the all.equal
function. Or rather, since all.equal
gives lots of detail about the differences if there are any, isTRUE(all.equal(...))
.
if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")
yields
i equals 0.15
Some more examples of using all.equal
instead of ==
(the last example is supposed to show that this will correctly show differences).
0.1+0.05==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.05, 0.15))
#[1] TRUE
1-0.1-0.1-0.1==0.7
#[1] FALSE
isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
#[1] TRUE
0.3/0.1 == 3
#[1] FALSE
isTRUE(all.equal(0.3/0.1, 3))
#[1] TRUE
0.1+0.1==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.1, 0.15))
#[1] FALSE
Some more detail, directly copied from an answer to a similar question:
The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.
while R lies slightly when you say:
1.1-0.2
#[1] 0.9
0.9
#[1] 0.9
You can find out what it really thinks in decimal:
sprintf("%.54f",1.1-0.2)
#[1] "0.900000000000000133226762955018784850835800170898437500"
sprintf("%.54f",0.9)
#[1] "0.900000000000000022204460492503130808472633361816406250"
You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:
sprintf("%a",0.9)
#[1] "0x1.ccccccccccccdp-1"
sprintf("%a",1.1-0.2)
#[1] "0x1.ccccccccccccep-1"
sprintf("%a",1.1-0.2-0.9)
#[1] "0x1p-53"
You can see that they differ by 2^-53
, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.
We can find out for any given computer what this smallest representable number is by looking in R's machine field:
?.Machine
#....
#double.eps the smallest positive floating-point number x
#such that 1 + x != 1. It equals base^ulp.digits if either
#base is 2 or rounding is 0; otherwise, it is
#(base^ulp.digits) / 2. Normally 2.220446e-16.
#....
.Machine$double.eps
#[1] 2.220446e-16
sprintf("%a",.Machine$double.eps)
#[1] "0x1p-52"
You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal
.
?all.equal
#....
#all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
#....
#all.equal(target, current,
# tolerance = .Machine$double.eps ^ 0.5,
# scale = NULL, check.attributes = TRUE, ...)
#....
So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.
This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.
Comparing vectors
The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. ==
is vectorized (does an element-wise comparison) while all.equal
compares the whole vectors as a single entity.
Using the previous examples
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)
==
does not give the "expected" result and all.equal
does not perform element-wise
a==b
#[1] FALSE FALSE FALSE FALSE
all.equal(a,b)
#[1] "Mean relative difference: 0.01234568"
isTRUE(all.equal(a,b))
#[1] FALSE
Rather, a version which loops over the two vectors must be used
mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
#[1] TRUE TRUE TRUE FALSE
If a functional version of this is desired, it can be written
elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})
which can be called as just
elementwise.all.equal(a, b)
#[1] TRUE TRUE TRUE FALSE
Alternatively, instead of wrapping all.equal
in even more function calls, you can just replicate the relevant internals of all.equal.numeric
and use implicit vectorization:
tolerance = .Machine$double.eps^0.5
# this is the default tolerance used in all.equal,
# but you can pick a different tolerance to match your needs
abs(a - b) < tolerance
#[1] TRUE TRUE TRUE FALSE
add a comment |
up vote
36
down vote
Adding to Brian's comment (which is the reason) you can over come this by using all.equal
instead:
# i <- 0.1
# i <- i + 0.05
# i
#if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
#i equals 0.15
Per Joshua's warning here is the updated code (Thanks Joshua):
i <- 0.1
i <- i + 0.05
i
if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
cat("i equals 0.15n")
} else {
cat("i does not equal 0.15n")
}
#i equals 0.15
I missed Brian's link which explains my response succinctly.
– Tyler Rinker
Feb 29 '12 at 23:57
14
all.equal
doesn't returnFALSE
when there are differences, so you need to wrap it withisTRUE
when using it in anif
statement.
– Joshua Ulrich
Mar 1 '12 at 0:49
add a comment |
up vote
9
down vote
This is hackish, but quick:
if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
2
But you can use theall.equal(... tolerance)
parameter.all.equal(0.147, 0.15, tolerance=0.05)
is TRUE.
– smci
May 28 at 11:25
add a comment |
up vote
0
down vote
dplyr::near()
is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:
sqrt(2) ^ 2 == 2
#> [1] FALSE
library(dplyr)
near(sqrt(2) ^ 2, 2)
#> [1] TRUE
The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5
that can be adjusted. The default parameter is the same as the default for all.equal()
.
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
303
down vote
accepted
General (language agnostic) reason
Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.
This is a well known limitation of computer arithmetic and is discussed in several places:
- The R FAQ has question devoted to it: R FAQ 7.31
The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)- David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)
- The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic
0.30000000000000004.com compares floating point arithmetic across programming languages- Several Stack Overflow questions including
- Why Are Floating Point Numbers Inaccurate?
- Why can't decimal numbers be represented exactly in binary?
- Is floating point math broken?
Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)
Comparing scalars
The standard solution to this in R
is not to use ==
, but rather the all.equal
function. Or rather, since all.equal
gives lots of detail about the differences if there are any, isTRUE(all.equal(...))
.
if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")
yields
i equals 0.15
Some more examples of using all.equal
instead of ==
(the last example is supposed to show that this will correctly show differences).
0.1+0.05==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.05, 0.15))
#[1] TRUE
1-0.1-0.1-0.1==0.7
#[1] FALSE
isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
#[1] TRUE
0.3/0.1 == 3
#[1] FALSE
isTRUE(all.equal(0.3/0.1, 3))
#[1] TRUE
0.1+0.1==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.1, 0.15))
#[1] FALSE
Some more detail, directly copied from an answer to a similar question:
The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.
while R lies slightly when you say:
1.1-0.2
#[1] 0.9
0.9
#[1] 0.9
You can find out what it really thinks in decimal:
sprintf("%.54f",1.1-0.2)
#[1] "0.900000000000000133226762955018784850835800170898437500"
sprintf("%.54f",0.9)
#[1] "0.900000000000000022204460492503130808472633361816406250"
You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:
sprintf("%a",0.9)
#[1] "0x1.ccccccccccccdp-1"
sprintf("%a",1.1-0.2)
#[1] "0x1.ccccccccccccep-1"
sprintf("%a",1.1-0.2-0.9)
#[1] "0x1p-53"
You can see that they differ by 2^-53
, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.
We can find out for any given computer what this smallest representable number is by looking in R's machine field:
?.Machine
#....
#double.eps the smallest positive floating-point number x
#such that 1 + x != 1. It equals base^ulp.digits if either
#base is 2 or rounding is 0; otherwise, it is
#(base^ulp.digits) / 2. Normally 2.220446e-16.
#....
.Machine$double.eps
#[1] 2.220446e-16
sprintf("%a",.Machine$double.eps)
#[1] "0x1p-52"
You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal
.
?all.equal
#....
#all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
#....
#all.equal(target, current,
# tolerance = .Machine$double.eps ^ 0.5,
# scale = NULL, check.attributes = TRUE, ...)
#....
So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.
This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.
Comparing vectors
The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. ==
is vectorized (does an element-wise comparison) while all.equal
compares the whole vectors as a single entity.
Using the previous examples
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)
==
does not give the "expected" result and all.equal
does not perform element-wise
a==b
#[1] FALSE FALSE FALSE FALSE
all.equal(a,b)
#[1] "Mean relative difference: 0.01234568"
isTRUE(all.equal(a,b))
#[1] FALSE
Rather, a version which loops over the two vectors must be used
mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
#[1] TRUE TRUE TRUE FALSE
If a functional version of this is desired, it can be written
elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})
which can be called as just
elementwise.all.equal(a, b)
#[1] TRUE TRUE TRUE FALSE
Alternatively, instead of wrapping all.equal
in even more function calls, you can just replicate the relevant internals of all.equal.numeric
and use implicit vectorization:
tolerance = .Machine$double.eps^0.5
# this is the default tolerance used in all.equal,
# but you can pick a different tolerance to match your needs
abs(a - b) < tolerance
#[1] TRUE TRUE TRUE FALSE
add a comment |
up vote
303
down vote
accepted
General (language agnostic) reason
Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.
This is a well known limitation of computer arithmetic and is discussed in several places:
- The R FAQ has question devoted to it: R FAQ 7.31
The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)- David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)
- The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic
0.30000000000000004.com compares floating point arithmetic across programming languages- Several Stack Overflow questions including
- Why Are Floating Point Numbers Inaccurate?
- Why can't decimal numbers be represented exactly in binary?
- Is floating point math broken?
Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)
Comparing scalars
The standard solution to this in R
is not to use ==
, but rather the all.equal
function. Or rather, since all.equal
gives lots of detail about the differences if there are any, isTRUE(all.equal(...))
.
if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")
yields
i equals 0.15
Some more examples of using all.equal
instead of ==
(the last example is supposed to show that this will correctly show differences).
0.1+0.05==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.05, 0.15))
#[1] TRUE
1-0.1-0.1-0.1==0.7
#[1] FALSE
isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
#[1] TRUE
0.3/0.1 == 3
#[1] FALSE
isTRUE(all.equal(0.3/0.1, 3))
#[1] TRUE
0.1+0.1==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.1, 0.15))
#[1] FALSE
Some more detail, directly copied from an answer to a similar question:
The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.
while R lies slightly when you say:
1.1-0.2
#[1] 0.9
0.9
#[1] 0.9
You can find out what it really thinks in decimal:
sprintf("%.54f",1.1-0.2)
#[1] "0.900000000000000133226762955018784850835800170898437500"
sprintf("%.54f",0.9)
#[1] "0.900000000000000022204460492503130808472633361816406250"
You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:
sprintf("%a",0.9)
#[1] "0x1.ccccccccccccdp-1"
sprintf("%a",1.1-0.2)
#[1] "0x1.ccccccccccccep-1"
sprintf("%a",1.1-0.2-0.9)
#[1] "0x1p-53"
You can see that they differ by 2^-53
, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.
We can find out for any given computer what this smallest representable number is by looking in R's machine field:
?.Machine
#....
#double.eps the smallest positive floating-point number x
#such that 1 + x != 1. It equals base^ulp.digits if either
#base is 2 or rounding is 0; otherwise, it is
#(base^ulp.digits) / 2. Normally 2.220446e-16.
#....
.Machine$double.eps
#[1] 2.220446e-16
sprintf("%a",.Machine$double.eps)
#[1] "0x1p-52"
You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal
.
?all.equal
#....
#all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
#....
#all.equal(target, current,
# tolerance = .Machine$double.eps ^ 0.5,
# scale = NULL, check.attributes = TRUE, ...)
#....
So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.
This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.
Comparing vectors
The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. ==
is vectorized (does an element-wise comparison) while all.equal
compares the whole vectors as a single entity.
Using the previous examples
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)
==
does not give the "expected" result and all.equal
does not perform element-wise
a==b
#[1] FALSE FALSE FALSE FALSE
all.equal(a,b)
#[1] "Mean relative difference: 0.01234568"
isTRUE(all.equal(a,b))
#[1] FALSE
Rather, a version which loops over the two vectors must be used
mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
#[1] TRUE TRUE TRUE FALSE
If a functional version of this is desired, it can be written
elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})
which can be called as just
elementwise.all.equal(a, b)
#[1] TRUE TRUE TRUE FALSE
Alternatively, instead of wrapping all.equal
in even more function calls, you can just replicate the relevant internals of all.equal.numeric
and use implicit vectorization:
tolerance = .Machine$double.eps^0.5
# this is the default tolerance used in all.equal,
# but you can pick a different tolerance to match your needs
abs(a - b) < tolerance
#[1] TRUE TRUE TRUE FALSE
add a comment |
up vote
303
down vote
accepted
up vote
303
down vote
accepted
General (language agnostic) reason
Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.
This is a well known limitation of computer arithmetic and is discussed in several places:
- The R FAQ has question devoted to it: R FAQ 7.31
The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)- David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)
- The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic
0.30000000000000004.com compares floating point arithmetic across programming languages- Several Stack Overflow questions including
- Why Are Floating Point Numbers Inaccurate?
- Why can't decimal numbers be represented exactly in binary?
- Is floating point math broken?
Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)
Comparing scalars
The standard solution to this in R
is not to use ==
, but rather the all.equal
function. Or rather, since all.equal
gives lots of detail about the differences if there are any, isTRUE(all.equal(...))
.
if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")
yields
i equals 0.15
Some more examples of using all.equal
instead of ==
(the last example is supposed to show that this will correctly show differences).
0.1+0.05==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.05, 0.15))
#[1] TRUE
1-0.1-0.1-0.1==0.7
#[1] FALSE
isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
#[1] TRUE
0.3/0.1 == 3
#[1] FALSE
isTRUE(all.equal(0.3/0.1, 3))
#[1] TRUE
0.1+0.1==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.1, 0.15))
#[1] FALSE
Some more detail, directly copied from an answer to a similar question:
The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.
while R lies slightly when you say:
1.1-0.2
#[1] 0.9
0.9
#[1] 0.9
You can find out what it really thinks in decimal:
sprintf("%.54f",1.1-0.2)
#[1] "0.900000000000000133226762955018784850835800170898437500"
sprintf("%.54f",0.9)
#[1] "0.900000000000000022204460492503130808472633361816406250"
You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:
sprintf("%a",0.9)
#[1] "0x1.ccccccccccccdp-1"
sprintf("%a",1.1-0.2)
#[1] "0x1.ccccccccccccep-1"
sprintf("%a",1.1-0.2-0.9)
#[1] "0x1p-53"
You can see that they differ by 2^-53
, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.
We can find out for any given computer what this smallest representable number is by looking in R's machine field:
?.Machine
#....
#double.eps the smallest positive floating-point number x
#such that 1 + x != 1. It equals base^ulp.digits if either
#base is 2 or rounding is 0; otherwise, it is
#(base^ulp.digits) / 2. Normally 2.220446e-16.
#....
.Machine$double.eps
#[1] 2.220446e-16
sprintf("%a",.Machine$double.eps)
#[1] "0x1p-52"
You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal
.
?all.equal
#....
#all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
#....
#all.equal(target, current,
# tolerance = .Machine$double.eps ^ 0.5,
# scale = NULL, check.attributes = TRUE, ...)
#....
So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.
This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.
Comparing vectors
The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. ==
is vectorized (does an element-wise comparison) while all.equal
compares the whole vectors as a single entity.
Using the previous examples
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)
==
does not give the "expected" result and all.equal
does not perform element-wise
a==b
#[1] FALSE FALSE FALSE FALSE
all.equal(a,b)
#[1] "Mean relative difference: 0.01234568"
isTRUE(all.equal(a,b))
#[1] FALSE
Rather, a version which loops over the two vectors must be used
mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
#[1] TRUE TRUE TRUE FALSE
If a functional version of this is desired, it can be written
elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})
which can be called as just
elementwise.all.equal(a, b)
#[1] TRUE TRUE TRUE FALSE
Alternatively, instead of wrapping all.equal
in even more function calls, you can just replicate the relevant internals of all.equal.numeric
and use implicit vectorization:
tolerance = .Machine$double.eps^0.5
# this is the default tolerance used in all.equal,
# but you can pick a different tolerance to match your needs
abs(a - b) < tolerance
#[1] TRUE TRUE TRUE FALSE
General (language agnostic) reason
Since not all numbers can be represented exactly in IEEE floating point arithmetic (the standard that almost all computers use to represent decimal numbers and do math with them), you will not always get what you expected. This is especially true because some values which are simple, finite decimals (such as 0.1 and 0.05) are not represented exactly in the computer and so the results of arithmetic on them may not give a result that is identical to a direct representation of the "known" answer.
This is a well known limitation of computer arithmetic and is discussed in several places:
- The R FAQ has question devoted to it: R FAQ 7.31
The R Inferno by Patrick Burns devotes the first "Circle" to this problem (starting on page 9)- David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," ACM Computing Surveys 23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)
- The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic
0.30000000000000004.com compares floating point arithmetic across programming languages- Several Stack Overflow questions including
- Why Are Floating Point Numbers Inaccurate?
- Why can't decimal numbers be represented exactly in binary?
- Is floating point math broken?
Canonical duplicate for "floating point is inaccurate" (a meta discussion about a canonical answer for this issue)
Comparing scalars
The standard solution to this in R
is not to use ==
, but rather the all.equal
function. Or rather, since all.equal
gives lots of detail about the differences if there are any, isTRUE(all.equal(...))
.
if(isTRUE(all.equal(i,0.15))) cat("i equals 0.15") else cat("i does not equal 0.15")
yields
i equals 0.15
Some more examples of using all.equal
instead of ==
(the last example is supposed to show that this will correctly show differences).
0.1+0.05==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.05, 0.15))
#[1] TRUE
1-0.1-0.1-0.1==0.7
#[1] FALSE
isTRUE(all.equal(1-0.1-0.1-0.1, 0.7))
#[1] TRUE
0.3/0.1 == 3
#[1] FALSE
isTRUE(all.equal(0.3/0.1, 3))
#[1] TRUE
0.1+0.1==0.15
#[1] FALSE
isTRUE(all.equal(0.1+0.1, 0.15))
#[1] FALSE
Some more detail, directly copied from an answer to a similar question:
The problem you have encountered is that floating point cannot represent decimal fractions exactly in most cases, which means you will frequently find that exact matches fail.
while R lies slightly when you say:
1.1-0.2
#[1] 0.9
0.9
#[1] 0.9
You can find out what it really thinks in decimal:
sprintf("%.54f",1.1-0.2)
#[1] "0.900000000000000133226762955018784850835800170898437500"
sprintf("%.54f",0.9)
#[1] "0.900000000000000022204460492503130808472633361816406250"
You can see these numbers are different, but the representation is a bit unwieldy. If we look at them in binary (well, hex, which is equivalent) we get a clearer picture:
sprintf("%a",0.9)
#[1] "0x1.ccccccccccccdp-1"
sprintf("%a",1.1-0.2)
#[1] "0x1.ccccccccccccep-1"
sprintf("%a",1.1-0.2-0.9)
#[1] "0x1p-53"
You can see that they differ by 2^-53
, which is important because this number is the smallest representable difference between two numbers whose value is close to 1, as this is.
We can find out for any given computer what this smallest representable number is by looking in R's machine field:
?.Machine
#....
#double.eps the smallest positive floating-point number x
#such that 1 + x != 1. It equals base^ulp.digits if either
#base is 2 or rounding is 0; otherwise, it is
#(base^ulp.digits) / 2. Normally 2.220446e-16.
#....
.Machine$double.eps
#[1] 2.220446e-16
sprintf("%a",.Machine$double.eps)
#[1] "0x1p-52"
You can use this fact to create a 'nearly equals' function which checks that the difference is close to the smallest representable number in floating point. In fact this already exists: all.equal
.
?all.equal
#....
#all.equal(x,y) is a utility to compare R objects x and y testing ‘near equality’.
#....
#all.equal(target, current,
# tolerance = .Machine$double.eps ^ 0.5,
# scale = NULL, check.attributes = TRUE, ...)
#....
So the all.equal function is actually checking that the difference between the numbers is the square root of the smallest difference between two mantissas.
This algorithm goes a bit funny near extremely small numbers called denormals, but you don't need to worry about that.
Comparing vectors
The above discussion assumed a comparison of two single values. In R, there are no scalars, just vectors and implicit vectorization is a strength of the language. For comparing the value of vectors element-wise, the previous principles hold, but the implementation is slightly different. ==
is vectorized (does an element-wise comparison) while all.equal
compares the whole vectors as a single entity.
Using the previous examples
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)
==
does not give the "expected" result and all.equal
does not perform element-wise
a==b
#[1] FALSE FALSE FALSE FALSE
all.equal(a,b)
#[1] "Mean relative difference: 0.01234568"
isTRUE(all.equal(a,b))
#[1] FALSE
Rather, a version which loops over the two vectors must be used
mapply(function(x, y) {isTRUE(all.equal(x, y))}, a, b)
#[1] TRUE TRUE TRUE FALSE
If a functional version of this is desired, it can be written
elementwise.all.equal <- Vectorize(function(x, y) {isTRUE(all.equal(x, y))})
which can be called as just
elementwise.all.equal(a, b)
#[1] TRUE TRUE TRUE FALSE
Alternatively, instead of wrapping all.equal
in even more function calls, you can just replicate the relevant internals of all.equal.numeric
and use implicit vectorization:
tolerance = .Machine$double.eps^0.5
# this is the default tolerance used in all.equal,
# but you can pick a different tolerance to match your needs
abs(a - b) < tolerance
#[1] TRUE TRUE TRUE FALSE
edited Jan 26 at 23:14
community wiki
13 revs, 5 users 66%
Brian Diggs
add a comment |
add a comment |
up vote
36
down vote
Adding to Brian's comment (which is the reason) you can over come this by using all.equal
instead:
# i <- 0.1
# i <- i + 0.05
# i
#if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
#i equals 0.15
Per Joshua's warning here is the updated code (Thanks Joshua):
i <- 0.1
i <- i + 0.05
i
if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
cat("i equals 0.15n")
} else {
cat("i does not equal 0.15n")
}
#i equals 0.15
I missed Brian's link which explains my response succinctly.
– Tyler Rinker
Feb 29 '12 at 23:57
14
all.equal
doesn't returnFALSE
when there are differences, so you need to wrap it withisTRUE
when using it in anif
statement.
– Joshua Ulrich
Mar 1 '12 at 0:49
add a comment |
up vote
36
down vote
Adding to Brian's comment (which is the reason) you can over come this by using all.equal
instead:
# i <- 0.1
# i <- i + 0.05
# i
#if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
#i equals 0.15
Per Joshua's warning here is the updated code (Thanks Joshua):
i <- 0.1
i <- i + 0.05
i
if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
cat("i equals 0.15n")
} else {
cat("i does not equal 0.15n")
}
#i equals 0.15
I missed Brian's link which explains my response succinctly.
– Tyler Rinker
Feb 29 '12 at 23:57
14
all.equal
doesn't returnFALSE
when there are differences, so you need to wrap it withisTRUE
when using it in anif
statement.
– Joshua Ulrich
Mar 1 '12 at 0:49
add a comment |
up vote
36
down vote
up vote
36
down vote
Adding to Brian's comment (which is the reason) you can over come this by using all.equal
instead:
# i <- 0.1
# i <- i + 0.05
# i
#if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
#i equals 0.15
Per Joshua's warning here is the updated code (Thanks Joshua):
i <- 0.1
i <- i + 0.05
i
if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
cat("i equals 0.15n")
} else {
cat("i does not equal 0.15n")
}
#i equals 0.15
Adding to Brian's comment (which is the reason) you can over come this by using all.equal
instead:
# i <- 0.1
# i <- i + 0.05
# i
#if(all.equal(i, .15)) cat("i equals 0.15n") else cat("i does not equal 0.15n")
#i equals 0.15
Per Joshua's warning here is the updated code (Thanks Joshua):
i <- 0.1
i <- i + 0.05
i
if(isTRUE(all.equal(i, .15))) { #code was getting sloppy &went to multiple lines
cat("i equals 0.15n")
} else {
cat("i does not equal 0.15n")
}
#i equals 0.15
edited Mar 1 '12 at 0:59
answered Feb 29 '12 at 23:56
Tyler Rinker
63k40222400
63k40222400
I missed Brian's link which explains my response succinctly.
– Tyler Rinker
Feb 29 '12 at 23:57
14
all.equal
doesn't returnFALSE
when there are differences, so you need to wrap it withisTRUE
when using it in anif
statement.
– Joshua Ulrich
Mar 1 '12 at 0:49
add a comment |
I missed Brian's link which explains my response succinctly.
– Tyler Rinker
Feb 29 '12 at 23:57
14
all.equal
doesn't returnFALSE
when there are differences, so you need to wrap it withisTRUE
when using it in anif
statement.
– Joshua Ulrich
Mar 1 '12 at 0:49
I missed Brian's link which explains my response succinctly.
– Tyler Rinker
Feb 29 '12 at 23:57
I missed Brian's link which explains my response succinctly.
– Tyler Rinker
Feb 29 '12 at 23:57
14
14
all.equal
doesn't return FALSE
when there are differences, so you need to wrap it with isTRUE
when using it in an if
statement.– Joshua Ulrich
Mar 1 '12 at 0:49
all.equal
doesn't return FALSE
when there are differences, so you need to wrap it with isTRUE
when using it in an if
statement.– Joshua Ulrich
Mar 1 '12 at 0:49
add a comment |
up vote
9
down vote
This is hackish, but quick:
if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
2
But you can use theall.equal(... tolerance)
parameter.all.equal(0.147, 0.15, tolerance=0.05)
is TRUE.
– smci
May 28 at 11:25
add a comment |
up vote
9
down vote
This is hackish, but quick:
if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
2
But you can use theall.equal(... tolerance)
parameter.all.equal(0.147, 0.15, tolerance=0.05)
is TRUE.
– smci
May 28 at 11:25
add a comment |
up vote
9
down vote
up vote
9
down vote
This is hackish, but quick:
if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
This is hackish, but quick:
if(round(i, 10)==0.15) cat("i equals 0.15") else cat("i does not equal 0.15")
answered Sep 7 '13 at 1:09
Hillary Sanders
2,00031937
2,00031937
2
But you can use theall.equal(... tolerance)
parameter.all.equal(0.147, 0.15, tolerance=0.05)
is TRUE.
– smci
May 28 at 11:25
add a comment |
2
But you can use theall.equal(... tolerance)
parameter.all.equal(0.147, 0.15, tolerance=0.05)
is TRUE.
– smci
May 28 at 11:25
2
2
But you can use the
all.equal(... tolerance)
parameter. all.equal(0.147, 0.15, tolerance=0.05)
is TRUE.– smci
May 28 at 11:25
But you can use the
all.equal(... tolerance)
parameter. all.equal(0.147, 0.15, tolerance=0.05)
is TRUE.– smci
May 28 at 11:25
add a comment |
up vote
0
down vote
dplyr::near()
is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:
sqrt(2) ^ 2 == 2
#> [1] FALSE
library(dplyr)
near(sqrt(2) ^ 2, 2)
#> [1] TRUE
The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5
that can be adjusted. The default parameter is the same as the default for all.equal()
.
add a comment |
up vote
0
down vote
dplyr::near()
is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:
sqrt(2) ^ 2 == 2
#> [1] FALSE
library(dplyr)
near(sqrt(2) ^ 2, 2)
#> [1] TRUE
The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5
that can be adjusted. The default parameter is the same as the default for all.equal()
.
add a comment |
up vote
0
down vote
up vote
0
down vote
dplyr::near()
is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:
sqrt(2) ^ 2 == 2
#> [1] FALSE
library(dplyr)
near(sqrt(2) ^ 2, 2)
#> [1] TRUE
The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5
that can be adjusted. The default parameter is the same as the default for all.equal()
.
dplyr::near()
is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs:
sqrt(2) ^ 2 == 2
#> [1] FALSE
library(dplyr)
near(sqrt(2) ^ 2, 2)
#> [1] TRUE
The function has a built in tolerance parameter: tol = .Machine$double.eps^0.5
that can be adjusted. The default parameter is the same as the default for all.equal()
.
answered Nov 9 at 3:31
sbha
1,90021822
1,90021822
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f9508518%2fwhy-are-these-numbers-not-equal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
5
See also stackoverflow.com/q/6874867 and stackoverflow.com/q/2769510. The R Inferno is also another great read.
– Aaron
Mar 1 '12 at 2:10