[Python-bugs-list] floating point ??? (PR#337)

[Tim Peters]

[slupi@iol.it]
> Full_Name: Sergio Lupi
> Version: 1.52
> OS: Linux Suse 6.4
> Submission from: (NULL) (195.78.220.33)
>
>
> very simple:

Actually not -- it's very complicated, and while it may be surprising it
isn't a bug.

> try this:
>
> >>> 0.14-0.13 == 0.13-0.12
> 1
> so far so good, but
>
> >>> 0.13-0.12 == 0.12-0.11
> 0
>
> There are some combinations of numbers (they are many indeed)
> that mess things up.

And not just in Python:  you'll get very similar results whether you try
this in Python, Perl, C, C++, Java, Fortran, or anything else that uses
binary floating-point arithmetic.  None of those numbers (.11, .12, .13,
.14) is exactly representable in binary fp, much as 1/3 isn't exactly
representable as a decimal expansion either:  0.3333.....  So, for example,
.14-.13 is NOT .01 -- it's a binary fraction that's simply close to .01.
Ditto for .12-.11:  it's some other binary fraction that's also close to
.01.  If you print your results to more precision, you'll see a better
approximation to the value the computer truly computes:

>>> print "%.17g" % (.12-.11)
0.009999999999999995
>>> print "%.17g" % (.13-.12)
0.010000000000000009
>>>

And, indeed, those clearly aren't equal.

> This has been tested on several PCs under Linux and NT

Yes, that's expected.  It doesn't really matter whose hardware, whose
operating system, or even whose programming language you're using:  this is
what binary floating-point hardware *does*.  If you need exact decimal
arithmetic, you can't use binary floating-point.  There are classes
available for Python that support (at least the illusion of) decimal
arithmetic instead, but they're very much slower.