[Numpy-discussion] what goes wrong with cos(), sin()

[David Goldsmith]

I grew up a TI guy - my recollection is that they stated in the user 
manual that though the display could show "only" 10 decimal digits, 
memory saved and computations used 16; perhaps nowadays it is even more, 
but unless you're doing millions of sequential calculations (how often 
do you do that on a handheld scientific calculator?) you shouldn't be 
seeing cumulative error problems, right?

DG

Christopher Barker wrote:
> Robert Kern wrote:
>   
>> Christopher Barker wrote:
>>     
>>> I wonder if there are any C math libs that do a better job than you'd 
>>> expect from standard FP? (short of unlimited precision ones)
>>>       
>> With respect to π and the zeros of sin() and cos()? Not really. If
>> numpy.sin(numpy.pi) were to give you 0.0, it would be *wrong*. numpy.sin() is
>> supposed to give you the most accurate result representable in double-precision
>> for the input you gave it.
>>     
>
> But does it?
>
>   
>> numpy.pi is not π.
>>     
>
> More precisely, it's the best IEEE754 64 bit FP approximation of pi.
>
> Right. I think that was the trick that HP used -- they somehow stored 
> and worked with pi with more digits. The things you can do if you're 
> making dedicated hardware.
>
> I do wonder if there would be some way to use the extended precision 
> built in to Intel FP hardware -- i.e. have a pi that you can pass in 
> that has the full 80 bits that can be used internally. I don't know if 
> the trig functions can be done with extended precision though.
>
> -Chris
>
>
>