On Wed, 02 Jul 2014 19:59:25 +0300, Marko Rauhamaa wrote: > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info>: > >> This is a problem with the underlying C double floating point format. >> Actually, it is not even a problem with the C format, since this >> problem applies to ANY floating point format, consequently this sort of >> thing plagues *every* programming language (unless they use >> arbitrary-precision rationals, but they have their own problems). > > Actually, it is not a problem at all. Floating-point numbers are a > wonderful thing.

## Advertising

No, *numbers* in the abstract mathematical sense are a wonderful thing. Concrete floating point numbers are a *useful approximation* to mathematical numbers. But they're messy, inexact, and fail to have the properties we expect real numbers to have, e.g. any of these can fail with IEEE-754 floating point numbers: 1/(1/x) == x x*(y+z) == x*y + x*z x + y - z == x - z + y x + y == x implies y == 0 You think maths is hard? That's *nothing* compared to reasoning about floating point numbers, where you cannot even expect x+1 to be different from x. In the Bad Old Days before IEEE-754, things were even worse! I've heard of CPUs where it was impossible to guard against DivideByZero errors: if x != 0: # succeeds print 1/x # divide by zero because the test for inequality tested more digits than the divider used. Ouch. >> This works because the Decimal type stores numbers in base 10, like you >> learned about in school, and so numbers that are exact in base 10 are >> (usually) exact in Decimal. > > Exactly, the problem is in our base 10 mind. No no no no! The problem is that *no matter what base you pick* some exact rational numbers cannot be represented in a finite number of digits. (Not to mention the irrationals.) > Note, however: > > >>> Decimal(1) / Decimal(3) * Decimal(3) > Decimal('0.9999999999999999999999999999') Yes! Because Decimal has a finite (albeit configurable) precision, while 1/3 requires infinite number of decimal places. Consequently, 1/Decimal(3) is a little bit smaller than 1/3, and multiplying by 3 gives you something a little bit smaller than 1. Ironically, in base 2, the errors in that calculation cancel out: py> 1/3*3 == 1 True and of course in base 3 the calculation would be exact. > Even "arbitrary-precision" rationals would suffer from the same problem: Not so. py> from fractions import Fraction py> Fraction(1, 3)*3 == 1 True "Arbitrary precision" rationals like Fraction are capable of representing *every rational number* exactly (provided you have enough memory). > >>> Rational(2).sqrt() * Rational(2).sqrt() == Rational(2) > False Square root of 2 is not a rational number. -- Steven -- https://mail.python.org/mailman/listinfo/python-list