problem with the 'math' module in 2.5?

[Chris]

from math import *1.0

The cosine function works fine, but I'm getting weird answers for sine.
Is this a bug? Am I doing something wrong?

 

[mensanator]

1.0

The cosine function works fine, but I'm getting weird answers for sine.
Is this a bug? Am I doing something wrong?

What answer do you suppose you get in version 2.4?

 

[Max Erickson]

1.0

The cosine function works fine, but I'm getting weird answers for
sine. Is this a bug? Am I doing something wrong?

From help(math) in an interactive window:

DESCRIPTION
This module is always available. It provides access to the
mathematical functions defined by the C standard.

So what you are seeing is the behavior of the C library being exposed.


Try sin(pi*0.5) to see similar behavior to cos(pi) or cos(pi*2).

 

[Chris]

sin(pi*0.5) is what I expected, but I expected to get 0 for sin(pi).

 

[Max Erickson]

Try sin(pi*0.5) to see similar behavior to cos(pi) or cos(pi*2).

Uhh, switch that, cos(pi*0.5)...

 

[Carsten Haese]

On 14 Oct 2006 20:33:13 -0700, Chris wrote

1.0

The cosine function works fine, but I'm getting weird answers for sine.
Is this a bug? Am I doing something wrong?

You're apparently not correctly reading python's answer to sin(pi).
1.2246063538223773e-016 is the scientific notation for the number
0.00000000000000012246063538223773, which is pretty darn close to zero, the
result you probably expected.

You're not getting *exactly* zero because you're not passing in *exactly* pi
but a close approximation of pi.

I'll leave it as an exercise for the reader to explain why cosine seems to
work fine. Hint: Look at cos(pi/2) and sin(pi/2).

-Carsten

 

[Chris]

I don't understand what that number came from. My calculator gives me
cos(pi*.5) = 0, and my interpreter gives me cos(pi*0.5) =
6.1230317691118863e-017.

 

[Chris]

Oh, ok that explains it. Is that why my 16-bit calculator gives me 0?

 

[David Lees]

sin(pi*0.5) is what I expected, but I expected to get 0 for sin(pi).

<snip>

http://docs.python.org/tut/node16.html

david

 

[Ben Finney]

Oh, ok that explains it. Is that why my 16-bit calculator gives me
0?

Your calculator is probably doing rounding without you asking for it.

Python refuses to guess what you want, and gives you the information
available.

 

[Gary Herron]

Your calculator is probably doing rounding without you asking for it.

Yes. Almost all calculators have 1 or 2 guard digits. These are extra
digits beyond what is shown on the display. All calculations are done at
that higher precision and the result are rounded to the precision of the
display for the user's benefit.

This satisfies users who know nothing about the numerical imprecision of
finite digit arithmetic. Python makes the opposite assumption that we
are are adults here and can handle the full knowledge, slight
imprecision and all.

Dr. Gary Herron

 

[Paddy]

Your calculator is probably doing rounding without you asking for it.

Python refuses to guess what you want, and gives you the information
available.

Hi Ben,
I don't think Python should take too much credit here. Floating point
calcuations are subject to rounding. Sometimes it shows.

- Pad.

 

[Jorgen Grahn]

You're not getting *exactly* zero because you're not passing in *exactly* pi
but a close approximation of pi.

That, plus the fact that floating-point math never is (in some sense)
precise. I am surprised noone brought up this one:
0.20000000000000001

The original poster should read more on the subject. The Wikipedia article
seems like a good place to start:

http://en.wikipedia.org/wiki/Floating-point

/Jorgen

 

[Ben Finney]

I don't think Python should take too much credit here.

I don't understand what you could mean by this. Credit for "giv[ing]
you the information available"? That's exactly what it's doing.

Floating point calcuations are subject to rounding. Sometimes it
shows.

And Python is showing it, rather than hiding it. It certainly isn't
doing any rounding unless asked to do so.

 

[andy2O]

sin(pi*0.5) is what I expected, but I expected to get 0 for sin(pi).

Computers in general, and Python too, usually use floating point
arithmetic in which all numbers are approximated by rational numbers of
a particular form (see http://en.wikipedia.org/wiki/Floating_point for
details).

1) pi is an irrational number, so it *cannot* be represented exactly in
floating point. Therefore the value of pi in your call to the sin
function is definitely, proveably, *not* exactly equal to the true
value of pi.

2) So, even if the function "sin" could be evaluated exactly, the fact
that you are not evaluating it exactly at the true value of pi, but
instead at a good but imperfect approximation to this value, means that
the sine function *should not* give the result = 0 for your request!

3) The function sin is also evaluated to only a finite degree of
precision - just like everything else in floating point arithmetic.
Therefore you should not expect absolutely precise results. Instead,
you need to understand the limitations of floating point arithmetic,
understand the precision you *can* expect, and work within these
bounds. It's a good system, but you do need to understand its
limitations. The links other people have posted are good resources for
this.

Best wishes,
andy

 

[Steven D'Aprano]

I don't think Python should take too much credit here.

I don't understand what you could mean by this. Credit for "giv[ing]
you the information available"? That's exactly what it's doing.

Floating point calcuations are subject to rounding. Sometimes it
shows.

And Python is showing it, rather than hiding it. It certainly isn't
doing any rounding unless asked to do so.

Python simply exposes whatever the C maths library does. The C maths
library is almost certainly doing some rounding: floats have only a finite
precision, which generally means the designer of the math library has two
choices: just truncate (chop) the calculation, or carry extra guard digits
(or bits) and round down. Most systems these days use guard digits, as
that is more accurate than truncating to a fixed precision.

If you mean that Python isn't doing *extra* rounding, above and beyond
what the C library is doing, you're correct. But rounding is happening.

This is a useful resource:

"What every computer scientist should know about floating-point
arithmetic"
http://docs.sun.com/source/806-3568/ncg_goldberg.html

To go back to the Original Poster's problem, he pointed out that his "16
bit calculator" gave a more accurate (but less precise) answer for
sin(pi), namely 0, instead of the more precise (but less accurate)
1.2246063538223773e-016 that Python reported. That just goes to show that,
sometimes, extra precision in floating point maths is a bad thing -- a
less precise library would actually have given a more correct answer.

This isn't strictly a Python question, but if there is anybody out there
who knows what the C library is doing, I'd appreciate an answer: since
sine is periodic, doesn't it make sense to reduce the argument modulo pi
before calculating the sine? Something like this:

def _sin(x):
x = x % math.pi
return math.sin(x)

Yes, you lose precision for large values of x because of the modulo, and
because math.pi isn't precisely pi, but that's got to be better than
losing precision for moderate values of x, surely? Have I missed something?

 

[Dennis Lee Bieber]

This isn't strictly a Python question, but if there is anybody out there
who knows what the C library is doing, I'd appreciate an answer: since
sine is periodic, doesn't it make sense to reduce the argument modulo pi
before calculating the sine? Something like this:

Well... I'd expect that, for any reasonably modern machine, the
library is just invoking some functions built into the floating point
unit of the processor. You'd have to ask the chip makers... (I seem to
recall that, for small angles -- in radians -- the sine can be
approximated by returning the angle itself:

)



A calculator, OTOH, probably doesn't have a floating point processor
-- many of them were built around 4-8bit processors using BCD notation
(two decimal digits per byte), and likely had look-up tables, with
interpolation, in ROM for the transcendental functions. The electronic
equivalent of looking up such values in a table in the CRC (or similar)
standard math tables book(s).
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/