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?

[Alex Martelli]

Andrew Dalke <ad****@mindspr ing.com> wrote:

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.

Yeah, everybody knows it's spelled "py"!
Alex

[Paul Foley]

On Mon, 20 Sep 2004 01:07:03 -0400, Tim Peters wrote:

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

Except in Indiana, where it's 4, of course.

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

[Paul Foley]

On 20 Sep 2004 02:08:54 +0200, Johan Ur Riise wrote:

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

Most CL implementations only support the hardware float types, that's
true, but it's not required by the spec.

CLISP's long-float has arbitrary precision (set by the user in
advance).

[And the Common Lisp type named "real" is the union of floats and
rationals; they're certainly not limited by hardware support]
--
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> "))

[Frithiof Andreas Jensen]

al*****@yahoo.c om (Alex Martelli) wrote in news:1gkdncx.ky q0oz1excwtyN%
al*****@yahoo.c om:

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

Oi!!! I resemble that remark !

;-)

[Alex Martelli]

Frithiof Andreas Jensen
<fr************ *@diespammerdie .jensen.tdcadsl .dk> wrote:

al*****@yahoo.c om (Alex Martelli) wrote in news:1gkdncx.ky q0oz1excwtyN%
al*****@yahoo.c om:

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

Oi!!! I resemble that remark !

;-)

OK, I should have used first person plural to count myself in, since,
after all, I _am_ an engineer...: _we_ mostly don't, but we like to kid
ourselves that we do!-)
Alex

[Heiko Wundram]

Am Sonntag, 19. September 2004 19:41 schrieb Alex Martelli:

gmpy (or to be more precise the underlying GMP library) runs optimally
on AMD Athlon 32-bit processors, which happen to be dirt cheap these
days, so a cleverly-purchased 300-dollars desktop Linux PC using such an
Athlon chip would no doubt let you use way more than these humble couple
thousand bits for such interactive computations while maintaining a
perfectly acceptable interactive response time.

But still, no algorithm implemented in software will ever beat the
FADD/FMUL/FDIV/FPOW/FSIN/FCOS etc. instructions in runtime, that was my
point... And error calculation is always possible, so that you can give
bounds to your result, even when using normal floating point arithmetic. And,
even when using GMPy, you have to know about the underlying limitations of
binary floating point so that you can reorganize your code if need be to add
precision (because one calculation might be much less precise if done in some
way than in another).

Heiko.

[Dan Bishop]

bo**@oz.net (Bengt Richter) wrote in message news:<ci******* *************** ***@theriver.co m>...

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 ? ;-)

Oops. I meant 884279719003555/281474976710656 .

[Alex Martelli]

Heiko Wundram <he*****@ceosg. de> wrote:

Am Sonntag, 19. September 2004 19:41 schrieb Alex Martelli:

gmpy (or to be more precise the underlying GMP library) runs optimally
on AMD Athlon 32-bit processors, which happen to be dirt cheap these
days, so a cleverly-purchased 300-dollars desktop Linux PC using such an
Athlon chip would no doubt let you use way more than these humble couple
thousand bits for such interactive computations while maintaining a
perfectly acceptable interactive response time.
But still, no algorithm implemented in software will ever beat the
FADD/FMUL/FDIV/FPOW/FSIN/FCOS etc. instructions in runtime, that was my

Yep, the hardware would have to be designed in a very lousy way for its
instructions to run slower than software running on the same CPU;-).

If you're not using some "vectorized " package such as Numeric or
numarray, though, it's unlikely that you care about speed -- and if you
_are_ using Numeric or numarray, it doesn't matter to you what type
Python itself uses for some literal such as 3.17292 -- it only matters
(speedwise) what your computational package is using (single precision,
double precision, whatever).
point... And error calculation is always possible, so that you can give
bounds to your result, even when using normal floating point arithmetic. And,
Sure! Your problems come when the bounds you compute are not good
enough for your purposes (given how deucedly loose error-interval
computations tend to be, that's going to happen more often than actual
accuracy loss in your computations... try an interval-arithmetic package
some day, to see what I mean...).
even when using GMPy, you have to know about the underlying limitations of
binary floating point so that you can reorganize your code if need be to add
precision (because one calculation might be much less precise if done in some
way than in another).

Sure. Throwing more precision at a badly analyzed and structured
algorithm is putting a band-aid on a wound. I _have_ taught numeric
analysis to undergrads and nobody could have passed my course unless
they had learned to quote that "party line" back at me, obviously.

In the real world, the band-aid stops the blood loss often enough that
few practising engineers and scientists are seriously motivated to
remember and apply all they've learned in their numeric analysis courses
(assuming they HAVE taken some: believe it or not, it IS quite possible
to get a degree in engineering, physics, etc, in most places, without
even getting ONE course in numeric analysis! the university where I
taught was an exception only for _some_ of the degrees they granted --
you couldn't graduate in _materials_ engineering without that course,
for example, but you COULD graduate in _buildings_ engineering while
bypassing it...).

Yes, this IS a problem. But I don't know what to do about it -- after
all, I _am_ quite prone to taking such shortcuts myself... if some
computation is giving me results that smell wrong, I just do it over
with 10 or 100 times more bits... yeah, I _do_ know that will only work
99.99% of the time, leaving a serious problem, possibly hidden and
unsuspected, more often than one can be comfortable with. In my case, I
have excuses -- I'm more likely to have fallen into some subtle trap of
_statistics_, making my precise computations pretty meaningless anyway,
than to be doing perfectly correct statistics in numerically smelly ways
(hey, I _have_ been brought up, as an example of falling into traps, in
"American Statistician", but not yet, AFAIK, in any journal dealing with
numerical analysis...:-).
Alex

[Dan Bishop]

Andrew Dalke <ad****@mindspr ing.com> wrote in message news:<QV******* **********@news read1.news.pas. earthlink.net>. ..

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

Or it could be 9.60 cubits across and 30.16 cubits around, and the
numbers are rounded to the nearest cubit.

Also, I've heard that the original Hebrew uses an uncommon spelling of
the word for "line" or "circumference" . Perhaps that affects the
meaning.

[Grant Edwards]

On 2004-09-20, david h <da***@dmh2000. com> wrote:

the problem with BCD or other 'decimal' computations is that it either
doesn't have the dynamic range of binary floating point (~ +-10**310)

Huh? Why would BCD floating point have any less range than
binary floating point? Due to the space inefficiencies of BCD,
it would take a few more bits to cover the same range, but I
don't see your point.

--
Grant Edwards grante Yow! Hey, LOOK!! A pair of
at SIZE 9 CAPRI PANTS!! They
visi.com probably belong to SAMMY
DAVIS, JR.!!