[Python-bugs-list] floating point ??? (PR#337)
Tue, 23 May 2000 23:27:38 -0400 (EDT)
> Full_Name: Sergio Lupi
> Version: 1.52
> OS: Linux Suse 6.4
> Submission from: (NULL) (220.127.116.11)
> 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
> so far so good, but
> >>> 0.13-0.12 == 0.12-0.11
> 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)
>>> print "%.17g" % (.13-.12)
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.