Floating point bug?

[Steven D'Aprano]

On Fri, 15 Feb 2008 10:55:47 -0800, Zentrader wrote:

> I disagree with this statement
> <quote>But that doesn't change the fact that it will expose the same
> rounding-errors as floats do - just for different numbers. </quote> The
> example used has no rounding errors.

Of course it does. Three thirds equals one, not 0.9999, or 
0.9999999999999999999999999999, or any other finite decimal 
representation. That's a rounding error, regardless of whether you are 
rounding in base 2 (like floats) or in base 10 (like Decimal does).


> Also you can compare two
> decimal.Decimal() objects for equality.  With floats you have to test
> for a difference less than some small value.

That's a superstition.

As a heuristic, it is often wise to lower your expectations when testing 
for equality. Since you often don't know how much rounding error will be 
introduced into a calculation, demanding that a calculation has zero 
rounding error is often foolish.

But good advice becomes a superstition when it becomes treated as a law: 
"never test floats for equality". That's simply not true. For example, 
floats are exact for whole numbers, up to the limits of overflow. If you 
know your floats are whole numbers, and still writing something like this:

x = 1234.0
y = 1000.0 + 200.0 + 30.0 + 4.0
if abs(x-y) < 1e-12:
    print "x and y are equal"

then you are wasting your time and guilty of superstitious behaviour.

Similarly for fractional powers of two.

x = 1/2 + 1/4 + 1/8 + 1/16
y = 1.0 - 1/32 - 1/32
assert x == y


-- 
Steven