Math errors in python

[Alex Martelli]

Re: Math errors in python

Andrew Dalke <adalke@mindspr ing.com> wrote:
[color=blue]
> Uncle Tim:[color=green]
> > That's absurd. pi is 3[/color]
>
> 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.[/color]

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


Alex

[Paul Foley]

Re: Math errors in python

On Mon, 20 Sep 2004 01:07:03 -0400, Tim Peters wrote:
[color=blue]
> [Chris S.][color=green]
>> Sqrt is a fair criticism, but Pi equals 22/7, exactly the form this
>> arithmetic is meant for.[/color][/color]
[color=blue]
> That's absurd. pi is 3,[/color]

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]

Re: Math errors in python

On 20 Sep 2004 02:08:54 +0200, Johan Ur Riise wrote:
[color=blue]
> 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:[/color]
[color=blue]
> (+ 1210/100 830/100)
> 102/5[/color]
[color=blue]
> (coerce * 'float)
> 20.4[/color]
[color=blue]
> 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[/color]

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]

Re: Math errors in python

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

[color=blue]
> 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!-).
>[/color]

Oi!!! I resemble that remark !

;-)

[Alex Martelli]

Re: Math errors in python

Frithiof Andreas Jensen
<frithiof.jense n@diespammerdie .jensen.tdcadsl .dk> wrote:
[color=blue]
> aleaxit@yahoo.c om (Alex Martelli) wrote in news:1gkdncx.ky q0oz1excwtyN%
> aleaxit@yahoo.c om:
>[color=green]
> > 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!-).[/color]
>
> Oi!!! I resemble that remark !
>
> ;-)[/color]

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]

Re: Math errors in python

Am Sonntag, 19. September 2004 19:41 schrieb Alex Martelli:[color=blue]
> 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.[/color]

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]

Re: Math errors in python

bokr@oz.net (Bengt Richter) wrote in message news:<cilbv7$sh 7$0$216.39.172. 122@theriver.co m>...[color=blue]
> On 19 Sep 2004 15:24:31 -0700, danb_83@yahoo.c om (Dan Bishop) wrote:
> [...][color=green]
> >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 .[color=darkred]
> >>> divmod(45035996 27370496,281474 976710656)[/color][/color]
> (16L, 0L)
>
> a little glitch somewhere ? ;-)[/color]

Oops. I meant 884279719003555/281474976710656 .

[Alex Martelli]

Re: Math errors in python

Heiko Wundram <heikowu@ceosg. de> wrote:
[color=blue]
> Am Sonntag, 19. September 2004 19:41 schrieb Alex Martelli:[color=green]
> > 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.[/color]
>
> But still, no algorithm implemented in software will ever beat the
> FADD/FMUL/FDIV/FPOW/FSIN/FCOS etc. instructions in runtime, that was my[/color]

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).
[color=blue]
> point... And error calculation is always possible, so that you can give
> bounds to your result, even when using normal floating point arithmetic. And,[/color]

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...).
[color=blue]
> 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).[/color]

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]

Re: Math errors in python

Andrew Dalke <adalke@mindspr ing.com> wrote in message news:<QVu3d.538 3$gG4.1881@news read1.news.pas. earthlink.net>. ..[color=blue]
> Andrea:[color=green]
> > 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[/color]
>
> Or that the walls were 0.25 cubits thick, if you're talking
> inner diameter vs. outer. ;)[/color]

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]

Re: Math errors in python

On 2004-09-20, david h <daveh@dmh2000. com> wrote:
[color=blue]
> the problem with BCD or other 'decimal' computations is that it either
> doesn't have the dynamic range of binary floating point (~ +-10**310)[/color]

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

[Grant Edwards]

Re: Math errors in python

On 2004-09-20, Andrea Griffini <agriff@tin.i t> wrote:
[color=blue]
> 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[/color]

If you've only got 1 significant digit in your measured values,
then Pi == 3 is a prefectly reasonable value to use.

--
Grant Edwards grante Yow! Why is everything
at made of Lycra Spandex?
visi.com

[Dennis Lee Bieber]

Re: Math errors in python

On 20 Sep 2004 14:34:03 GMT, Grant Edwards <grante@visi.co m> declaimed
the following in comp.lang.pytho n:
[color=blue]
> On 2004-09-20, david h <daveh@dmh2000. com> wrote:
>[color=green]
> > the problem with BCD or other 'decimal' computations is that it either
> > doesn't have the dynamic range of binary floating point (~ +-10**310)[/color]
>
> 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.[/color]

There /was/ an "or" in that sentence, which you trimmed out...

Though working with numbers that are stored in >150 bytes
doesn't interest me. Uhm, actually, to handle the +/- exponent range,
make that 300+ bytes (150+ bytes before the decimal, and the same after
it). As soon as you start storing an exponent as a separate component
you introduce a loss of precision in computations.
--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.ne tcom.com/> <[/color]

[Grant Edwards]

Re: Math errors in python

On 2004-09-20, Dennis Lee Bieber <wlfraed@ix.net com.com> wrote:[color=blue]
> On 20 Sep 2004 14:34:03 GMT, Grant Edwards <grante@visi.co m> declaimed
> the following in comp.lang.pytho n:
>[color=green]
>> On 2004-09-20, david h <daveh@dmh2000. com> wrote:
>>[color=darkred]
>> > the problem with BCD or other 'decimal' computations is that it either
>> > doesn't have the dynamic range of binary floating point (~ +-10**310)[/color]
>>
>> 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.[/color]
>
> There /was/ an "or" in that sentence, which you trimmed out...[/color]

Sorry about that, but I wasn't addressing the other complaint,
just the lack of range part.
[color=blue]
> Though working with numbers that are stored in >150 bytes
> doesn't interest me. Uhm, actually, to handle the +/- exponent
> range, make that 300+ bytes (150+ bytes before the decimal,
> and the same after it).[/color]

To get the same range and precision as a 32-bit IEEE, you need
4 bytes for mantissa and 2 for the exponent. That's 6 bytes,
not 300.
[color=blue]
> As soon as you start storing an exponent as a separate
> component you introduce a loss of precision in computations.[/color]

I thought you were complaining about range and storage required
for BCD vs. binary.

Floating point BCD can have the same range and precision and
binary floating point with about a 50% penalty in storage
space.

If you're going to compare fixed point verses floating point,
that's a completely separate (and orthogonal) issue.

--
Grant Edwards grante Yow! Let's send the
at Russians defective
visi.com lifestyle accessories!

[Carl Banks]

Re: Math errors in python

"Chris S." <chrisks@NOSPAM .udel.edu> wrote in message news:<70b3d.182 2$uz1.747@trndn y03>...[color=blue]
> I just find
> it funny how a $20 calculator can be more accurate than Python running
> on a $1000 Intel machine.[/color]

Actually, if you look at Intel's track record, it isn't that surprising.

How many Intel Pentium engineers does it take to change a light bulb?
Three. One to screw in the bulb, and one to hold the ladder.

--
CARL BANKS

[Grant Edwards]

Re: Math errors in python

On 2004-09-21, Carl Banks <imbosol@aerojo ckey.com> wrote:[color=blue]
> "Chris S." <chrisks@NOSPAM .udel.edu> wrote in message news:<70b3d.182 2$uz1.747@trndn y03>...[color=green]
>> I just find
>> it funny how a $20 calculator can be more accurate than Python running
>> on a $1000 Intel machine.[/color]
>
> Actually, if you look at Intel's track record, it isn't that surprising.
>
> How many Intel Pentium engineers does it take to change a light bulb?
> Three. One to screw in the bulb, and one to hold the ladder.[/color]

Intel, where quality is Job 0.9999999997.

--
Grant Edwards grante Yow! My CODE of ETHICS
at is vacationing at famed
visi.com SCHROON LAKE in upstate
New York!!