# Math errors in python

Dan Bishop danb_83 at yahoo.com
Mon Sep 20 06:07:55 CEST 2004

```Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote in message news:<7xfz5ein0h.fsf at ruckus.brouhaha.com>...
> Gary Herron <gherron at islandtraining.com> writes:
> > Any representation of the infinity of numbers on a finite computer
> > *must* necessarily be unable to represent some (actually infinity
> > many) of those numbers.  The inaccuracies stem from that fact.
>
> Well, finite computers can't even represent all the integers, but
> we can reasonably think of Python as capable of doing exact integer
> arithmetic.
>
> 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,

That may confusing for non-C programmers, but it's easy to explain.
The real flaw of old-style division is that code like

def mean(seq):
return sum(seq) / len(seq)

subtly fails when seq happens to contain all integers, and you can't
even correctly use:

def mean(seq):
return 1.0 * sum(seq) / len(seq)

because it could lose accuracy if seq's elements were of a custom
high-precision numeric type that is closed under integer division but
gets coerced to float when multiplied by a float.

> That doesn't solve the also very
> common confusion that (1.0/3.0)*3.0 = 0.99999999.

What problem?

>>> (1.0 / 3.0) * 3.0
1.0

The rounding error of multiplying 1/3 by 3 happens to exactly cancel
out that of dividing 1 by 3.  It's an accident, but you can use it as
a quick argument against the "decimal arithmetic is always more
acurate" crowd.

> Rational arithmetic can solve that.

Yes, it can, and imho it would be a good idea to use rational
arithmetic as the default for integer division (but _not_ as a general
replacement for float).

```