>>from math import *

0.0

1.2246063538223773e-016

-2.4492127076447545e-016

1.0

-1.0

1.0

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

Chris wrote:

0.0

1.2246063538223773e-016

-2.4492127076447545e-016

1.0

-1.0

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?

"Chris" <chrispatton@gmail.comwrote:

0.0

1.2246063538223773e-016

-2.4492127076447545e-016

1.0

-1.0

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

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

Max Erickson wrote:

"Chris" <chrispatton@gmail.comwrote:
>

>

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

Max Erickson <maxerickson@gmail.comwrote:

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

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

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

0.0

1.2246063538223773e-016

-2.4492127076447545e-016

1.0

-1.0

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

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.

Max Erickson wrote:

Max Erickson <maxerickson@gmail.comwrote:

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

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

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

>
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 wrote:

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

"Chris" <chrispatton@gmail.comwrites:

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.

--
\ "Earth gets its price for what Earth gives us." -- James |
`\ Russell Lowell |
_o__) |
Ben Finney

Ben Finney wrote:

"Chris" <chrispatton@gmail.comwrites:
>
>

>
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

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

Ben Finney wrote:

"Chris" <chrispatton@gmail.comwrites:
>

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

On Sun, 15 Oct 2006 00:18:29 -0400, Carsten Haese <carsten@uniqsys.comwrote:
....

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

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org R'lyeh wgah'nagl fhtagn!

"Paddy" <paddy3118@netscape.netwrites:

Ben Finney wrote:

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

--
\ Legionnaire: "We have their leader captive!" C泡r: "Is he |
`\ bound?" Legionnaire: "Of his health I know not, sir." -- The |
_o__) Goon Show, _The Histories Of Pliny The Elder_ |
Ben Finney

Chris wrote:

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

On Sun, 15 Oct 2006 20:03:18 +1000, Ben Finney wrote:

"Paddy" <paddy3118@netscape.netwrites:
>

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

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


--
Steve.