Incremented floats do not equal each other

Question

Possible Duplicate:
Why can't decimal numbers be represented exactly in binary?
Program not entering if statement

So I'm trying to run a program that has two variables, when one variable is equal to another, it performs a function. In this case, printing spam. However, for some reason, when I run this program, I'm not getting any output even though I know they are equal.

g=0.0
b=3.0

while g < 30.0:
    if g==b:
        print "Hi"
    g+=.1
    print g, b

[What Every Computer Scientist Should Know About Floating-Point Arithmetic](http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html) — Peter Graham, Jul 25 '12 at 00:02

score 9 · Answer 1 · answered Jul 24 '12 at 23:51

9

You are assuming that adding .1 enough times to 0.0 will produce 3.0. These are floating point numbers, they are inaccurate. Rounding errors make it so that the value is never exactly equal to 3.0. You should almost never use == to test floating point numbers.

answered Jul 24 '12 at 23:51

Ned Batchelder

364,293
75
561
662

1

If you really need Decimal math with accuracy, you can use the `Decimal` module. But why you would is beyond the data the op has provided – tkone Jul 24 '12 at 23:54
The actual value of `g` after adding `0.1` a thirty times is `3.0000000000000013`. – Kijewski Jul 24 '12 at 23:57
1

Is this a viable alternative: `g = round(g+0.1, 1)` ? – inspectorG4dget Jul 25 '12 at 00:00
2

+1 for saying “almost never” use `==` rather than “never.” – Eric Postpischil Jul 25 '12 at 00:15

score 6 · Answer 2 · answered Jul 25 '12 at 00:20

A good way to do this is to count with integer values (e.g., loop with i from 0 to 300 by 1) and scale the counter only when the float value is used (e.g., set f = i * .1). When you do this, the loop counter is always exact, so you get exactly the iterations you want, and there is only one floating-point rounding, which does not accumulate from iteration to iteration.

The loop counter is most commonly an integer type, so that addition is easily seen to be exact (until overflow is reached). However, the loop counter may also be a floating-point type, provided you are sure that the values and operations for it are exact. (The common 32-bit floating-point format represents integers exactly from -2²⁴ to +2²⁴. Outside that, it does not have the precision to represent integers exactly. It does not represent .1 exactly, so you cannot count with increments of .1. But you could count with increments of .5, .25, .375, or other small multiples of moderate powers of two, which are represented exactly.)

score 0 · Answer 3 · answered Jul 25 '12 at 00:28

To expand on Karoly Horvath's comment, what you can do to test near-equality is choose some value (let's call it epsilon) that is very, very small relative to the minimum increment. Let's say epsilon is 1.0 * 10^-6, five orders of magnitude smaller than your increment. (It should probably be based on the average rounding error of your floating point representation, but that varies, and this is simply an example).

What you then do is check if g and b are less than epsilon different - if they are close enough that they are practically equal, the difference between practically and actually being the rounding error, which you're approximating with epsilon.

Check for

abs(g - b) < epsilon

and you'll have your almost-but-not-quite equality check, which should be good enough for most purposes.

Incremented floats do not equal each other

3 Answers3