Math errors in python

Alex Martelli aleaxit at
Sun Sep 19 19:21:50 CEST 2004

Paul Rubin <> wrote:
> The issue here is that Python's behavior confuses the hell out of some
> new users.  There is a separate area of confusion, that
>    a = 2 / 3
> sets a to 0, and to clear that up, the // operator was introduced and
> Python 3.0 will supposedly treat / as floating-point division even
> when both operands are integers.  That doesn't solve the also very
> common confusion that (1.0/3.0)*3.0 = 0.99999999.  Rational arithmetic
> can solve that.

Yes, but applying rational arithmetic by default might slow some
computations far too much for beginners' liking!  My favourite for
Python 3.0 would be to have decimals by default, with special notations
to request floats and rationals (say '1/3r' for a rational, '1/3f' for a
float, '1/3' or '1/3d' for a decimal with some default parameters such
as number of digits).  This is because my guess is that most naive users
would _expect_ decimals by default...

> Yes, with rational arithmetic, it will still be true that
> sqrt(5.)**2.0 doesn't quite equal 5, but hardly anyone ever complains
> about that.
> And yes, there are languages that can do exact arithmetic on arbitrary
> algebraic numbers, but they're normally not used for general-purpose
> programming.

Well, you can pretty easily use constructive reals with Python, see for
example <> -- that's a
vastly vaster set than just algebraic numbers.  If we DO want precision,
after all, why should sqrt(5) be more important than log(3)?


More information about the Python-list mailing list