52847 # Why are these numbers not equal?

Question:

## Since not all numbers can be represented exactly in <a href="http://en.wikipedia.org/wiki/IEEE_floating_point" rel="nofollow">IEEE floating point arithmetic</a> (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: <ul><li>The R FAQ has question devoted to it: <a href="http://cran.r-project.org/doc/FAQ/R-FAQ.html#Why-doesn_0027t-R-think-these-numbers-are-equal_003f" rel="nofollow">R FAQ 7.31</a></li> <li><a href="http://www.burns-stat.com/pages/Tutor/R_inferno.pdf" rel="nofollow">The R Inferno by Patrick Burns</a> devotes the first "Circle" to this problem (starting on page 9)</li> <li>David Goldberg, "What Every Computer Scientist Should Know About Floating-point Arithmetic," <em>ACM Computing Surveys</em> <strong>23</strong>, 1 (1991-03), 5-48 <a href="http://dx.doi.org/10.1145/103162.103163" rel="nofollow">doi>10.1145/103162.103163</a> (<a href="http://www.validlab.com/goldberg/paper.pdf" rel="nofollow">revision also available</a>)</li> <li><a href="http://floating-point-gui.de/" rel="nofollow">The Floating-Point Guide - What Every Programmer Should Know About Floating-Point Arithmetic</a></li> <li><a href="http://0.30000000000000004.com" rel="noreferrer">0.30000000000000004.com</a> compares floating point arithmetic across programming languages</li> <li>Several Stack Overflow questions including <ul><li><a href="https://stackoverflow.com/q/21895756/892313" rel="nofollow">Why Are Floating Point Numbers Inaccurate?</a></li> <li><a href="https://stackoverflow.com/q/1089018/892313" rel="nofollow">Why can't decimal numbers be represented exactly in binary?</a></li> <li><a href="https://stackoverflow.com/q/588004/892313" rel="nofollow">Is floating point math broken?</a></li> <li><a href="https://meta.stackoverflow.com/q/260130/892313" rel="nofollow">Canonical duplicate for "floating point is inaccurate"</a> (a meta discussion about a canonical answer for this issue)</li> </ul></li> </ul>

Comparing scalars

## The standard solution to this in `R` is not to use <a href="https://www.rdocumentation.org/packages/base/topics/Comparison" rel="nofollow">`==`</a>, but rather the <a href="https://www.rdocumentation.org/packages/base/topics/all.equal" rel="nofollow">`all.equal`</a> 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 # FALSE isTRUE(all.equal(0.1+0.05, 0.15)) # TRUE 1-0.1-0.1-0.1==0.7 # FALSE isTRUE(all.equal(1-0.1-0.1-0.1, 0.7)) # TRUE 0.3/0.1 == 3 # FALSE isTRUE(all.equal(0.3/0.1, 3)) # TRUE 0.1+0.1==0.15 # FALSE isTRUE(all.equal(0.1+0.1, 0.15)) # FALSE ```Some more detail, directly copied from an <a href="https://stackoverflow.com/a/2228139/892313" rel="nofollow">answer to a similar question</a>: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 # 0.9 0.9 # 0.9 ```You can find out what it really thinks in decimal:```sprintf("%.54f",1.1-0.2) # "0.900000000000000133226762955018784850835800170898437500" sprintf("%.54f",0.9) # "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) # "0x1.ccccccccccccdp-1" sprintf("%a",1.1-0.2) # "0x1.ccccccccccccep-1" sprintf("%a",1.1-0.2-0.9) # "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 <a href="https://www.rdocumentation.org/packages/base/topics/.Machine" rel="nofollow">machine</a> 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 # 2.220446e-16 sprintf("%a",.Machine\$double.eps) # "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