Math errors in python

[Gary Herron]

On Sunday 19 September 2004 01:00 am, Chris S. wrote:
> Gary Herron wrote:
> > That's called rational arithmetic, and I'm sure you can find a package
> > that implements it for you.  However what would you propose for
> > irrational numbers like sqrt(2) and transcendental numbers like PI?
>
> Sqrt is a fair criticism, but Pi equals 22/7, 

What? WHAT?  Are you nuts?  Pi and 22/7 are most certainly not equal.
They don't even share three digits beyond the decimal point.  (Can you
really be that ignorant about numbers and expect to contribute
intelligently to a discussion about numbers.  Pi is a non-repeating
and non-ending number in base 10 or any other base.)


> exactly the form this
> arithmetic is meant for. Any decimal can be represented by a fraction,
> yet not all fractions can be represented by decimals. My point is that
> such simple accuracy should be supported out of the box.
>
> > While I'd love to compute with all those numbers in infinite
> > precision, we're all stuck with FINITE sized computers, and hence with
> > the inaccuracies of finite representations of numbers.
>
> So are our brains, yet we somehow manage to compute 12.10 + 8.30
> correctly using nothing more than simple skills developed in
> grade-school. You could theoretically compute an infinitely long
> equation by simply operating on single digits, yet Python, with all of
> its resources, can't overcome this hurtle?
>
> However, I understand Python's limitation in this regard. This
> inaccuracy stems from the traditional C mindset, which typically
> dismisses any approach not directly supported in hardware. As the FAQ
> states, this problem is due to the "underlying C platform". I just find
> it funny how a $20 calculator can be more accurate than Python running
> on a $1000 Intel machine.

If you are happy doing calculations with decimal numbers like 12.10 +
8.30, then the Decimal package may be what you want, but that fails as
soon as you want 1/3.  But then you could use a rational arithmetic
package and get 1/3, but that would fail as soon as you needed sqrt(2)
or Pi.  But then you could try ... what?  Can you see the pattern
here?  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.

Hardware designers have settled on a binary representation of floating
point numbers, and both C and Python use the underlying hardware
implementation.  (Try your calculation in C -- you'll get the same
result if you choose to print out enough digits.)

And BTW, your calculator is not, in general, more accurate than the
modern IEEE binary hardware representation of numbers used on most of
today's computers.  It is more accurate on only a select subset of all
numbers, and it does a good job of fooling you in those cases where it
loses accuracy, by doing calculations on more digits then it displays,
and rounding off to the on-screen digits.

So while a calculator will fool you into believing it is accurate when
it is not, it is Python's design decision to not cater to fools.

Dr Gary Herron