Math errors in python

[Radioactive Man]

In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
following types of errors whenever I do simple arithmetic:

1st example:

12.10 + 8.30 20.399999999999 999 1.1 - 0.2 0.9000000000000 0013
2nd example(no errors here): bool(130.0 - 129.0 == 1.0) True
3rd example: a = 0.013
b = 0.0129
c = 0.0001
[a, b, c] [0.0129999999999 99999, 0.0129, 0.0001] bool((a - b) == c)

False
This sort of error is no big deal in most cases, but I'm sure it could
become a problem under certain conditions, particularly the 3rd
example, where I'm using truth testing. The same results occur in all
cases whether I define variables a, b, and c, or enter the values
directly into the bool statement. Also, it doesn't make a difference
whether "a = 0.013" or "a = 0.0130".

I haven't checked this under windows 2000 or XP, but I expect the same
thing would happen. Any suggestions for a way to fix this sort of
error?

[Chris S.]

Alex Martelli wrote:

If he's not a troll, he _should_ be -- it's just too sad to consider the
possibility that somebody is really that ignorant and arrogant at the
same time (although, tragically, human nature is such as to make that
entirely possible). Nevertheless, newsgroups and mailing lists have an
interesting characteristic: no "thoughtful answer" need ever be truly
wasted, even if the person you're answering is not just a troll, but a
robotized one, _because there are other readers_ which may find
interest, amusement, or both, in that answer. On a newsgroup, or
very-large-audience mailing list, one doesn't really write just for the
person you're nominally answering, but for the public at large.

Exactly. One could wonder if more timid accusations would have
engendered such insightful and accurate responses. However, I do
apologize if I appeared trollish. Thank you for your contributions.

[Dan Bishop]

Gary Herron <gh*****@island training.com> wrote in message news:<ma******* *************** *************** *@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 450359962737049 6/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.

[Alex Martelli]

Paul Rubin <http://ph****@NOSPAM.i nvalid> wrote:

al*****@yahoo.c om (Alex Martelli) writes:

Yes, but applying rational arithmetic by default might slow some
computations far too much for beginners' liking!

I dunno, lots of Lisp dialects do rational arithmetic by default.

And...? What fractions of beginners get exposed to Lisp as their first
language just love the resulting precision/speed tradeoff...? I think
Paul Graham's "Worse is Better" article applies quite well here...

Well, you can pretty easily use constructive reals with Python, see for
example <http://more.btexact.co m/people/briggsk2/XR.html> -- 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)?

I don't know that it's generally tractable to do exact computation on
constructive reals. How do you implement comparison (<, >, ==)?

Well, if you can generate decimal representations on demand (and you'd
better, as the user might ask for such output at any time with any
a-priori unpredictable number of digits), worst case you can compare
them lexicographical ly, one digit at a time, until you find a different
digit (assuming identical signs and integer parts) -- except that equal
numbers would not terminate by this procedure. Briggs' implementation
finesses the issue by comparing no more than k significant digits, 1000
by default;-)
Alex

[Bengt Richter]

On Sun, 19 Sep 2004 20:31:48 +0200, al*****@yahoo.c om (Alex Martelli) wrote:

Dennis Lee Bieber <wl*****@ix.net com.com> wrote:

Strangely, HP's tended not to hold guard digits... My HP-48sx
gives the all-9s result, and I recall older models also not having
guards.

Nothing strange there -- HP's calculators were squarely aimed at
scientists and engineers, who are supposed to know what they're doing
when it comes to numeric computation (they mostly _don't_, but they like
to kid themselves that they do!-).

ISTM we humans mostly persist in ignoring seemingly inconsequential flaws in our
mental maps of reality until we are sufficiently surprised or fail too long
to find something dear to us (whether numerical results, a surfing beach,
a better map, a love, a purpose, or ultimate enlightenment ;-)

Regards,
Bengt Richter

[Johan Ur Riise]

al*****@yahoo.c om (Alex Martelli) writes:

Paul Rubin <http://ph****@NOSPAM.i nvalid> wrote:

al*****@yahoo.c om (Alex Martelli) writes:

Yes, but applying rational arithmetic by default might slow some
computations far too much for beginners' liking!

I dunno, lots of Lisp dialects do rational arithmetic by default.

And...? What fractions of beginners get exposed to Lisp as their first
language just love the resulting precision/speed tradeoff...? I think
Paul Graham's "Worse is Better" article applies quite well here...

There is not much of a precision/speed tradoff in Common Lisp, you can
use fractional numbers (which give you exact results with operations
+, -, * and /) internally and round them off to decimal before
display. With the OP's example:

(+ 1210/100 830/100)
102/5

(coerce * 'float)
20.4

Integers can have unlimited number of digits, but the precision of
floats and reals are still limited to what the hardware can do, so if
you want to display for instance 2/3 with lots of decimals, you have
to multiply it first and insert the decimal point yourself, like in

(format t ".~d" (round (* 2/3 100000000000000 00000)))
..6666666666666 666667

Of course, long integers (bignums) are slower than short (fixnums), but
with automatic conversion to and fro, you pay the penalty only when
you need it.

[Bengt Richter]

On Sun, 19 Sep 2004 14:41:53 +0200, Peter Otten <__*******@web. de> wrote:

Paul Rubin wrote:

Peter Otten <__*******@web. de> writes:

Starting with Python 2.4 there will be the 'decimal' module supporting
"arithmetic the way you know it":

>>> from decimal import *
>>> Decimal("12.10" ) + Decimal("8.30")

I haven't tried 2.4 yet. After

The auther is currently working on an installer, but just dropping it into
2.3's site-packages should work, too.

a = Decimal("1") / Decimal("3")
b = a * Decimal("3")
print b

What happens? Is that arithmetic as the way I know it?

Decimal as opposed to rational:

from decimal import *
Decimal(1)/Decimal(3)Decimal("0.333 333333333333333 3333333333") 3*_Decimal("0.999 999999999999999 9999999999")

Many people can cope with the inaccuracy induced by base 10 representations
and are taken by surprise by base 2 errors.
But you are right I left too much room for interpretation.

I hacked a little rational + decimal exponent representation based toy a while
back. The original post had a bug, which someone pointed out and I posted a
followup fix for, but the revised version was not posted. But I can if someone
is interested.

from ut.exactdec import ED
ED(1)/ED(3) ED('1 / 3') 3*_ ED('1')

If you give it a float, it wants to know how many decimals you mean: ED(1./3) Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "c:\pywk\ut\exa ctdec.py", line 93, in __init__
raise ValueError(
ValueError: Specify decimals for least significant digit of 10**(-decimals)
(decimals may also be specified as 'all' to capture all bits of float)
ED(1./3, 'all') ED('0.333333333 333333314829616 256247390992939 472198486328125 ')

If you give it a string literal, it takes it as accurate, but you can round it
to create a new accurate number: ED('1/3', 54) ED('0.333333333 333333333333333 333333333333333 333333333333333 ') ED('1/3', 60) ED('0.333333333 333333333333333 333333333333333 333333333333333 333333')

That's an accurate number that has all zeroes to the right of those 60 3's ED('1/3', 60)*3 ED('0.999999999 999999999999999 999999999999999 999999999999999 999999')

If you don't round, you get a fully accurate result" ED('1/3')*3 ED('1')

It's interesting to look at pi: import math
math.pi 3.1415926535897 931 ED(math.pi, 'all') ED('3.141592653 589793115997963 468544185161590 576171875') ED(3.1415926535 897931, 'all') ED('3.141592653 589793115997963 468544185161590 576171875')

Same actual exact decimal value gets created from
repr(math.pi) '3.141592653589 7931'

meaning they both have the same floating point hardware representation,
but the short version decimal literal is sufficient to set all the bits right
even though it doesn't represent the fully exact value in decimal.
Economy courtesy of the Timbot I think ;-)

I don't know what the rules in Decimal are for stage-wise rounding vs keeping
accuracy, but I imagine you could get the same kind of surprises that are
available in binary from floating point, e.g.,
from ut.exactdec import ED
Floating point: acc = 1.0
for i in xrange(100): acc += 1e-300 ... acc 1.0

That really is exactly 1.0 ED(acc,'all')
Now the calculation accurately:
ED('1') ecc = ED(1)
for i in xrange(100): ecc += ED('1e-300') ... ecc ED('1.000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000
000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000
000000000000000 1') ecc-1

ED('1.0e-298')

If you add a small Decimal delta repeatedly, will it get rounded away like the floating point
version, or will accuracy get promoted, or what? Sorry, I haven't read the docs yet ;-/

Regards,
Bengt Richter

[Bengt Richter]

On 19 Sep 2004 15:24:31 -0700, da*****@yahoo.c om (Dan Bishop) wrote:
[...]

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 450359962737049 6/281474976710656 .

divmod(45035996 27370496,281474 976710656) (16L, 0L)

a little glitch somewhere ? ;-)

Others are nice though, but the last one shows up same way:
print '%s\n%s' %(ED('312689/99532').round(1 1), ED(math.pi,11)) ED('3.141592653 62')
ED('3.141592653 59') print '%s\n%s' %(ED('3126535/995207').round( 13), ED(math.pi,13)) ED('3.141592653 5887')
ED('3.141592653 5898') print '%s\n%s' %(ED('450359962 7370496/281474976710656 '), ED(math.pi,'all '))

ED('16')
ED('3.141592653 589793115997963 468544185161590 576171875')

Regards,
Bengt Richter

[Bengt Richter]

On 20 Sep 2004 00:35:33 GMT, bo**@oz.net (Bengt Richter) wrote:
[...]

If you add a small Decimal delta repeatedly, will it get rounded away like the floating point
version, or will accuracy get promoted, or what? Sorry, I haven't read the docs yet ;-/

I needn't have used 1e-300 to get the effect -- 1e-16 is relatively small enough:

acc = 1.0
for i in xrange(100): acc += 1e-16 ... acc 1.0 ED(acc, 'all') ED('1') ecc = ED(1)
for i in xrange(100): ecc += ED('1e-16') ... ecc

ED('1.000000000 00001')

Regards,
Bengt Richter

[Radioactive Man]

Thanks to all for info here. Sorry for inadvertently creating such a
long thread.

[Paul Foley]

On 19 Sep 2004 15:24:31 -0700, Dan Bishop wrote:

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 450359962737049 6/281474976710656 .

I hope not! That's equal to 16. (The double float closest to) pi is
884279719003555/281474976710656

--
Don't worry about people stealing your ideas. If your ideas are any good,
you'll have to ram them down people's throats.
-- Howard Aiken
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz> "))