2012-02-29 23:46:46 8 Comments

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
```

### Related Questions

#### Sponsored Content

#### 15 Answered Questions

### [SOLVED] Why not use Double or Float to represent currency?

**2010-09-16 19:23:57****Fran Fitzpatrick****251188**View**842**Score**15**Answer- Tags: floating-point currency

#### 33 Answered Questions

### [SOLVED] How do I check if a string is a number (float)?

**2008-12-09 20:03:42****Daniel Goldberg****1148894**View**1404**Score**33**Answer- Tags: python casting floating-point type-conversion

#### 27 Answered Questions

### [SOLVED] Format number to always show 2 decimal places

**2011-05-26 05:22:51****Varada****869938**View**638**Score**27**Answer- Tags: javascript floating-point number-formatting

#### 12 Answered Questions

### [SOLVED] Why doesn't GCC optimize a*a*a*a*a*a to (a*a*a)*(a*a*a)?

**2011-06-21 18:49:55****xis****193155**View**2042**Score**12**Answer- Tags: gcc assembly floating-point compiler-optimization fast-math

#### 34 Answered Questions

### [SOLVED] How to deal with floating point number precision in JavaScript?

**2009-09-22 07:34:42****Juri****306662**View**501**Score**34**Answer- Tags: javascript floating-point

#### 5 Answered Questions

### [SOLVED] Why does changing 0.1f to 0 slow down performance by 10x?

**2012-02-16 15:58:39****Dragarro****132252**View**1445**Score**5**Answer- Tags: c++ performance visual-studio-2010 compilation floating-point

#### 14 Answered Questions

#### 2 Answered Questions

### [SOLVED] Why doesn't 0.1+0.2+0.3 equals to 0.3+0.2+0.1?

**2018-05-31 10:05:23****ocomfd****749**View**5**Score**2**Answer- Tags: javascript floating-point floating-accuracy

#### 2 Answered Questions

#### 1 Answered Questions

### [SOLVED] Put integers from stdin in list

**2015-10-27 21:37:45****PeetZ****47**View**1**Score**1**Answer- Tags: python list floating-point stdin

## 5 comments

## @Elias EstatisticsEU 2019-02-22 16:46:01

I had a similar problem. I used the following solution.

output of unequal cut intervals based on options(digits = 2):

output of equal cut intervals based on round function:

## @sbha 2018-11-09 03:31:18

`dplyr::near()`

is an option for testing if two vectors of floating point numbers are equal. This is the example from the docs: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()`

.## @Brian Diggs 2012-02-29 23:49:55

## 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:

ACM Computing Surveys23, 1 (1991-03), 5-48 doi>10.1145/103162.103163 (revision also available)## 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(...))`

.yields

Some more examples of using

`all.equal`

instead of`==`

(the last example is supposed to show that this will correctly show differences).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:

You can find out what it really thinks in decimal:

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:

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:

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`

.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

`==`

does not give the "expected" result and`all.equal`

does not perform element-wiseRather, a version which loops over the two vectors must be used

If a functional version of this is desired, it can be written

which can be called as just

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:## @Hillary Sanders 2013-09-07 01:09:33

This is hackish, but quick:

## @smci 2018-05-28 11:25:42

But you can use the

`all.equal(... tolerance)`

parameter.`all.equal(0.147, 0.15, tolerance=0.05)`

is TRUE.## @Tyler Rinker 2012-02-29 23:56:00

Adding to Brian's comment (which is the reason) you can over come this by using

`all.equal`

instead:Per Joshua's warning here is the updated code (Thanks Joshua):## @Tyler Rinker 2012-02-29 23:57:21

I missed Brian's link which explains my response succinctly.

## @Joshua Ulrich 2012-03-01 00:49:18

`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.