Math errors in python

[Chris S.]

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]

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.

 

[Alex Martelli]

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

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 lexicographically, 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]

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]

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 10000000000000000000)))
..6666666666666666667

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]

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


Decimal as opposed to rational:

Decimal("0.9999999999999999999999999999")

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.
ED('1')

If you give it a float, it wants to know how many decimals you mean: Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "c:\pywk\ut\exactdec.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('0.333333333333333314829616256247390992939472198486328125')

If you give it a string literal, it takes it as accurate, but you can round it
to create a new accurate number: ED('0.333333333333333333333333333333333333333333333333333333333333')

That's an accurate number that has all zeroes to the right of those 60 3's ED('0.999999999999999999999999999999999999999999999999999999999999')

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

It's interesting to look at pi: ED('3.141592653589793115997963468544185161590576171875')

Same actual exact decimal value gets created from '3.1415926535897931'

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

Floating point: 1.0

That really is exactly 1.0
Now the calculation accurately:
ED('1') ED('1.000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000001') 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, (e-mail address removed) (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 4503599627370496/281474976710656.

(16L, 0L)

a little glitch somewhere ? ;-)

Others are nice though, but the last one shows up same way:
ED('3.14159265362')
ED('3.14159265359') ED('3.1415926535887')
ED('3.1415926535898') ED('16')
ED('3.141592653589793115997963468544185161590576171875')

Regards,
Bengt Richter

 

[Bengt Richter]

On 20 Sep 2004 00:35:33 GMT, (e-mail address removed) (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:
ED('1.00000000000001')

Regards,
Bengt Richter

 

[Radioactive Man]

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

 

[Paul Foley]

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.

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>"))

 

[Dan Bishop]

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

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

 

[david h]

the problem with BCD or other 'decimal' computations is that it either
doesn't have the dynamic range of binary floating point (~ +-10**310)
or if it has unlimited digits then there is a LOT of software cranking
to do the math, whereas binary floating point is in the hardware. If
you want the language to use binary floating point (fast) but do the
rounding for you, then fine, but then you will have problems using it
for any real numerical task because the issue of rounding is very
important to numerical analysis, and is done different ways in
different cases. Every time the language runtime rounds for you, it is
introducing errors to your computations that you may or may not want.
There is a large body of knowledge surrounding the use of IEEE 754
floating point representation and if the language diverges from that
then users who want to do numerical analysis won't use it.

another question: do you want the math package to round for you, or do
you want the IO package to do it only when you print? You will get
different results from each. I could imagine a language runtime could
have a switch that tells it to automatically round the results for
you, either in the math or the IO.

 

[Tim Peters]

[Paul Rubin]

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

Equality of constructive reals is undecidable. In practice, CR
packages allow specifying a "number of digits of evidence " parameter
N, so that equality is taken to mean "provably don't differ by more
than a unit in the N'th digit".

 

[Tim Peters]

[Chris S.]

Sqrt is a fair criticism, but Pi equals 22/7, exactly the form this
arithmetic is meant for.

That's absurd. pi is 3, and nothing but grief comes from listening to
fancy-pants so-called "mathematicians" trying to convince you that
their inability to find integer results is an intellectual failing you
should share <wink>.

 

[Bengt Richter]

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

Amazingly, that is _exactly_ equal to math.pi
True
(3141592653589793115997963468544185161590576171875L, 1L, -48)

So it's also equal to the rational number
3141592653589793115997963468544185161590576171875 / 10**48
... '/1000000000000000000000000000000000000000000000000')
ED('3.141592653589793115997963468544185161590576171875')

or
ED('3.141592653589793115997963468544185161590576171875')

Regards,
Bengt Richter

 

[Tim Peters]

[Bengt Richter]

...
If you add a small Decimal delta repeatedly, will it get rounded away like the
floating point version,

Decimal *is* a floating-point type, containing most of IEEE 854 (the
radix-generalized variant of IEEE 754). It's got infinities, signed
zeroes, NaNs, ..., all that FP hair. Decimal specifies unnormalized
fp, though, so there's no special class of "denormal" values in
Decimal.

or will accuracy get promoted,

No, but the number of digits of precision is user-specifiable. In all
places this makes sense, the result of an operation is the exact
(infinite precision) mathematical result, rounded once to the current
context precision, according to the current context rounding mode. If
you want 100 digits, ask for 100 digits -- but you have to ask in
advance.

 

[Andrea Griffini]

Also, the
IEEE 754 double-precision representation of pi is equal to the
rational number 4503599627370496/281474976710656.

I know the real uses of a precise pi are not that many... but
isn't that a quite raw approximation ? that fraction equals 16...

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.

For monetary computation why not using fixed point instead
(i.e. integers representing the number of thousands of cents,
for example) ? IMO using floating point instead of something
like arbitrary precision integers is looking for trouble in
that area as often what is required is accuracy up to a
specified fraction of the unit.

Andrea

PS: From a study seems that 75.7% of people tends to believe
more in messages that contain precise numbers (like 75.7%).

 

[Andrea Griffini]

[Chris S.]

Sqrt is a fair criticism, but Pi equals 22/7, exactly the form this
arithmetic is meant for.

That's absurd. pi is 3, and nothing but grief comes from listening to
fancy-pants so-called "mathematicians" trying to convince you that
their inability to find integer results is an intellectual failing you
should share <wink>.

This is from the Bible...

007:023 And he made a molten sea, ten cubits from the one brim to the
other: it was round all about, and his height was five cubits:
and a line of thirty cubits did compass it round about.

So it's clear that pi must be 3

Andrea

 

[Andrew Dalke]

Uncle Tim:

That's absurd. pi is 3

Personally I've found that pie is usually round, though
if you're talking price I agree -- I can usually get a
slice for about $3, more like $3.14 with tax. I like
mine apple, with a bit of ice cream.

Strange spelling though.

Andrew
(e-mail address removed)

 

[Andrew Dalke]

Andrea:

This is from the Bible...

007:023 And he made a molten sea, ten cubits from the one brim to the
other: it was round all about, and his height was five cubits:
and a line of thirty cubits did compass it round about.

So it's clear that pi must be 3

Or that the walls were 0.25 cubits thick, if you're talking
inner diameter vs. outer.

Andrew
(e-mail address removed)