Math errors in python

Dan Bishop danb_83 at yahoo.com
Sun Sep 19 18:24:31 EDT 2004


Gary Herron <gherron at islandtraining.com> wrote in message news:<mailman.3494.1095586574.5135.python-list at python.org>...
> 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.

There are, of course, reasonably accurate rational approximations of
pi.  For example, 355/113 (accurate to 6 decimal places), 312689/99532
(9 decimal places), or 3126535/995207 (11 decimal places).  Also, the
IEEE 754 double-precision representation of pi is equal to the
rational number 4503599627370496/281474976710656.

> ...Pi is a non-repeating and non-ending number in base 10 or any other base.)

It has a terminating representation in base pi ;-)

But you're right that it has a non-repeating and non-ending
representation in any _useful_ base.

> 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.

True, but who says we need to use the same representation for all
numbers.  Python _could_ use rationals in situations where they'd work
(like int/int division), and only revert to floating-point when
necessary (like math.sqrt and math.pi).

> 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.

In general, it's _less_ accurate.  In IEEE 754 double-precision,
machine epsilon is 2**-53 (about 1e-16), but TI's calculators have a
machine epsilon of 1e-14.  Thus, in general, IEEE 754 gives you about
2 more digits of precision than a calculator.

> It is more accurate on only a select subset of all numbers,

Right.  In most cases, base 10 has no inherent advantage.  The number
1.41 is a _less_ accurate representation of sqrt(2) than 0x1.6A.  The
number 3.14 is a less accurate representation of pi than 0x3.24.  And
it's not inherently more accurate to say that my height is 1.80 meters
rather than 0x1.CD meters or 5'11".

Base 10 _is_ more accurate for monetary amounts, and for this reason I
agreed with the addition of a decimal class.  But it would be a
mistake to use decimal arithmetic, which has a performance
disadvantage with no accuracy advantage, in the general case.



More information about the Python-list mailing list