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

[David M. Cooke]

On Feb 21, 2007, at 14:54 , Christopher Barker wrote:

> Anne Archibald wrote:
>> Or, to see more clearly, try taking (on a pocket calculator, say)
>> sin(3.14) (or even sin(pi)).
>
> This is an interesting point. I took a class from William Kahan once
> (pass/fail, thank god!), and one question he posed to us was:
>
> How many digits of pi is used in an HP calculator?

FWIW,

There are two data types for reals (at least on the HP 28 and 48  
series, and others in that line): a 12 decimal digit real used for  
communicating with the user, and an extended 15 decimal digit real  
used internally. All calculations are done in base 10.

The exponent e for the 12-digit real is in the range -500 < e < 500,  
and for the 15-digit, -5 < e < 5.

AFAIK, most of HP's calculators are like this.

-- 
|>|\/|<
/--\
|David M. Cooke  http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Christopher Barker]

David L Goldsmith wrote:
> I agree w/ Chuck - I'd consider what Tim describes is happening a "bug".

It's not a bug, but it is a missing feature. numpy doesn't appear to 
convert strings to numbers for any of its own types:

 >>> N.float128("4.3")
Traceback (most recent call last):
   File "", line 1, in 
TypeError: a float is required
 >>> N.uint8("4")
Traceback (most recent call last):
   File "", line 1, in 
ValueError: setting an array element with a sequence.
 >>> N.uint16("4")
Traceback (most recent call last):
   File "", line 1, in 
ValueError: setting an array element with a sequence.
 >>> N.int16("4")
Traceback (most recent call last):
   File "", line 1, in 
ValueError: setting an array element with a sequence.

It works for "float" and "int":
 >>> N.float("4")
4.0
 >>> N.int("4")
4

Because these are built-in python types, and those constructors support 
initialization with strings.

Given that there are some numpy types that hold values that can not be 
initialized by standard python literals, it would be nice to be able to 
do this.

Oh, and here's another inconsistency:

 >>> N.int32("676")
676
 >>> N.uint32("676")
array([6, 7, 6], dtype=uint32)

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[David L Goldsmith]

I agree w/ Chuck - I'd consider what Tim describes is happening a "bug".

DG

Charles R Harris wrote:
>
>
> On 2/21/07, *Timothy Hochberg* <[EMAIL PROTECTED] 
> > wrote:
>
>
>
> On 2/21/07, *Charles R Harris* < [EMAIL PROTECTED]
> > wrote:
>
>
>
> On 2/21/07, *Robert Kern* < [EMAIL PROTECTED]
> > wrote:
>
> 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.
>
>
> 
>
> Well, you can always use long double if it is implemented
> on your platform. You
> will have to construct a value for π yourself, though. I'm
> afraid that we don't
> really make that easy.
>
> --
>
>
> pi = 3. 1415926535 8979323846 2643383279 5028841971 6939937510
> 5820974944 5923078164 0628620899 8628034825 3421170679
> 8214808651 *...
>
> *
> I dont know what that looks like when converted to long
> double. Lessee,
>
> In [1]: import numpy
>
> In [2]: pi =
> numpy.float128(3.1415926535897932384626433832795028841971)
>
>
> I think this is where you go wrong. Your string of digits is first
> a python float and *then* is converted to a long double. In the
> intermediate stage it gets truncated and you don't get the
> precision back.
>
>
> True. But there is missing functionality here.
>
> In [4]: pi = numpy.float128('3.1415926535897932384626433832795028841971')
> --- 
>
> exceptions.TypeError Traceback (most 
> recent call last)
>
> /home/charris/workspace/microsat/daemon/
>
> TypeError: a float is required
>  
> It's somewhat pointless to have a data type that you can't properly 
> initialize. I think the string value should work, it works for python 
> types.
>
> Chuck
>
> 
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>   


-- 
ERD/ORR/NOS/NOAA 
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On 2/21/07, Charles R Harris <[EMAIL PROTECTED]> wrote:




On 2/21/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
>
>
>
> On 2/21/07, Charles R Harris < [EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On 2/21/07, Robert Kern < [EMAIL PROTECTED]> wrote:
> > >
> > > 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.
> >
> >
> > 
> >
> > Well, you can always use long double if it is implemented on your
> > > platform. You
> > > will have to construct a value for π yourself, though. I'm afraid
> > > that we don't
> > > really make that easy.
> > >
> > > --
> >
> >
> > pi = 3. 1415926535 8979323846 2643383279 5028841971 6939937510
> > 5820974944 5923078164 0628620899 8628034825 3421170679 8214808651 *...
> >
> > *
> > I dont know what that looks like when converted to long double.
> > Lessee,
> >
> > In [1]: import numpy
> >
> > In [2]: pi = numpy.float128(3.1415926535897932384626433832795028841971
> > )
> >
>
> I think this is where you go wrong. Your string of digits is first a
> python float and *then* is converted to a long double. In the intermediate
> stage it gets truncated and you don't get the precision back.
>

True. But there is missing functionality here.

In [4]: pi = numpy.float128('3.1415926535897932384626433832795028841971')
---

exceptions.TypeError Traceback (most
recent call last)

/home/charris/workspace/microsat/daemon/

TypeError: a float is required

It's somewhat pointless to have a data type that you can't properly
initialize. I think the string value should work, it works for python types.




OTOH, the old way does give extended precision for pi

In [8]: numpy.arctan2(numpy.float128(1), numpy.float128(1))*4
Out[8]: 3.14159265358979323851

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On 2/21/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:




On 2/21/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
>
>
> On 2/21/07, Robert Kern < [EMAIL PROTECTED]> wrote:
> >
> > 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.
>
>
> 
>
> Well, you can always use long double if it is implemented on your
> > platform. You
> > will have to construct a value for π yourself, though. I'm afraid that
> > we don't
> > really make that easy.
> >
> > --
>
>
> pi = 3. 1415926535 8979323846 2643383279 5028841971 6939937510
> 5820974944 5923078164 0628620899 8628034825 3421170679 8214808651 *...
>
> *
> I dont know what that looks like when converted to long double. Lessee,
>
> In [1]: import numpy
>
> In [2]: pi = numpy.float128(3.1415926535897932384626433832795028841971)
>

I think this is where you go wrong. Your string of digits is first a
python float and *then* is converted to a long double. In the intermediate
stage it gets truncated and you don't get the precision back.



True. But there is missing functionality here.

In [4]: pi = numpy.float128('3.1415926535897932384626433832795028841971')
---
exceptions.TypeError Traceback (most recent
call last)

/home/charris/workspace/microsat/daemon/

TypeError: a float is required

It's somewhat pointless to have a data type that you can't properly
initialize. I think the string value should work, it works for python types.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Timothy Hochberg]

On 2/21/07, Charles R Harris <[EMAIL PROTECTED]> wrote:




On 2/21/07, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> 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.




Well, you can always use long double if it is implemented on your
> platform. You
> will have to construct a value for π yourself, though. I'm afraid that
> we don't
> really make that easy.
>
> --


pi = 3. 1415926535 8979323846 2643383279 5028841971 6939937510 5820974944
5923078164 0628620899 8628034825 3421170679 8214808651 *...

*
I dont know what that looks like when converted to long double. Lessee,

In [1]: import numpy

In [2]: pi = numpy.float128(3.1415926535897932384626433832795028841971)



I think this is where you go wrong. Your string of digits is first a python
float and *then* is converted to a long double. In the intermediate stage it
gets truncated and you don't get the precision back.


In [3]: numpy.pi - pi

Out[3]: 0.0

In [7]: '%25.20f'%numpy.pi
Out[7]: '   3.14159265358979311600 '

In [8]: '%25.20f'%pi
Out[8]: '   3.14159265358979311600'

I think we have a bug. Or else extended arithmetic isn't supported on this
machine.

Chuck



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion





--

//=][=\\

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On 2/21/07, Robert Kern <[EMAIL PROTECTED]> wrote:


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.





Well, you can always use long double if it is implemented on your platform.

You
will have to construct a value for π yourself, though. I'm afraid that we
don't
really make that easy.

--



pi = 3. 1415926535 8979323846 2643383279 5028841971 6939937510 5820974944
5923078164 0628620899 8628034825 3421170679 8214808651 *...

*
I dont know what that looks like when converted to long double. Lessee,

In [1]: import numpy

In [2]: pi = numpy.float128(3.1415926535897932384626433832795028841971)

In [3]: numpy.pi - pi
Out[3]: 0.0

In [7]: '%25.20f'%numpy.pi
Out[7]: '   3.14159265358979311600'

In [8]: '%25.20f'%pi
Out[8]: '   3.14159265358979311600'

I think we have a bug. Or else extended arithmetic isn't supported on this
machine.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Anne Archibald]

On 21/02/07, Robert Kern <[EMAIL PROTECTED]> wrote:

> Well, you can always use long double if it is implemented on your platform. 
> You
> will have to construct a value for π yourself, though. I'm afraid that we 
> don't
> really make that easy.

If the trig functions are implemented at all, you can probably use
atan2(-1,0) and get a decent approximation; alternatively, if you want
to use sin(pi)=0 as a definition you could use scipy's bisection
routine (which is datatype-independent, IIRC) to find pi. Or you could
probably use a rational approximation to pi, then convert numerator
and denominator to long doubles, or better yet compare the rational
number with your long double approximation of pi.

But no, not particularly easy.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Robert Kern]

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.

I'll back off on this a little bit. There are some approaches that will work;
they're not floating point, but they're not really "symbolic" computation 
either.

  http://keithbriggs.info/xrc.html

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

Not quite, it seems, but 0 is even farther from the correct answer, apparently:

[sage-2.0-intelmac-i386-Darwin]$ ./sage
--
| SAGE Version 2.0, Release Date: 2007-01-28 |
| Type notebook() for the GUI, and license() for information.|
--

sage: npi = RealNumber(3.1415926535897931, min_prec=53)
sage: npi.sin()
0.00013634246772254977
sage: import numpy
sage: numpy.sin(numpy.pi)
1.22460635382e-16

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

Well, you can always use long double if it is implemented on your platform. You
will have to construct a value for π yourself, though. I'm afraid that we don't
really make that easy.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Timothy Hochberg]

On 2/21/07, Christopher Barker <[EMAIL PROTECTED]> wrote:


Anne Archibald wrote:
> Or, to see more clearly, try taking (on a pocket calculator, say)
> sin(3.14) (or even sin(pi)).

This is an interesting point. I took a class from William Kahan once
(pass/fail, thank god!), and one question he posed to us was:

How many digits of pi is used in an HP calculator?

I never figured out the answer myself, and the question involved the
info that certain calculations involving pi being accurate to a certain
degree. I don't have my HP calculator with me right now but I suspect
that sin(pi) might well evaluate to exactly zero, or closer than 1e-16
anyway.



Not on my HP calcularor. However, mine is 20+ years old and the label has
worn off so I'm not even sure what model it is any more (15c?). However,
sin(pi) is -4.1e-10 on this calculator, FWIW.


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)

-Chris



--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion





--

//=][=\\

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [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
>
>
>   

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Christopher Barker]

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


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[David Goldsmith]

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. numpy.pi is not π.
>
>   
True, but since the string literal "numpy.pi" is not the same as the 
string literal "3.1415926535897931" there's no reason in principle why 
"numpy.py" couldn't symbolically represent the exact value; of course, 
since numpy does not otherwise support symbolic computation, such an 
adoption would be frivolous and rather silly (but then the Pythons were 
never afraid of being silly). :-)


DG
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Robert Kern]

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. numpy.pi is not π.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Christopher Barker]

Anne Archibald wrote:
> Or, to see more clearly, try taking (on a pocket calculator, say)
> sin(3.14) (or even sin(pi)).

This is an interesting point. I took a class from William Kahan once 
(pass/fail, thank god!), and one question he posed to us was:

How many digits of pi is used in an HP calculator?

I never figured out the answer myself, and the question involved the 
info that certain calculations involving pi being accurate to a certain 
degree. I don't have my HP calculator with me right now but I suspect 
that sin(pi) might well evaluate to exactly zero, or closer than 1e-16 
anyway.

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)

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

[EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[David Goldsmith]

Anne Archibald wrote:
> On 21/02/07, Zachary Pincus <[EMAIL PROTECTED]> wrote:
>
>   
>> A corrolary: in general do not two floating-point values for equality
>> -- use something like numpy.allclose. (Exception -- equality is
>> expected if the exact sequence of operations to generate two numbers
>> were identical.)
>> 
>
> I really can't agree that blindly using allclose() is a good idea. For
> example, allclose(plancks_constant,0) and the difference leads to
> quantum mechanics... you really have to know how much difference you
> expect and how big your numbers are going to be.
>
> Anne
>   
"Precisely!" ;-)

Last time we had a posting like this, didn't one of the respondents 
include a link to something within the numpy Web docs that talks about 
floating point precision?

DG
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>   

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[David Goldsmith]

As far as a computer is concerned, those numbers are "around" zero - 
"growing-up" w/ Matlab, e.g., one quickly learns to recognize these 
numbers for what they are.  One way to return zero for numbers like 
these is

if numpy.allclose(x, 0): return 0 (or 0*x to assure that 0 is the same 
type as x),

but caveat emptor: sometimes, of course, 1e-16 really is supposed to be 
1e-16, not just the best the algorithm can do to get to zero.  Also, 
(help me out here guys) I thought there was something like 
zeroifclose(x) which does the above, or does numpy only have realifclose 
to return a real when an imaginary part is close to zero?

DG

WolfgangZillig wrote:
> Hi,
>
> I'm quite new to numpy/scipy so please excuse if my problem is too obvious.
>
> example code:
>
> import numpy as n
> print n.sin(n.pi)
> print n.cos(n.pi/2.0)
>
> results in:
> 1.22460635382e-016
> 6.12303176911e-017
>
> I've expected something around 0. Can anybody explain what I am doing 
> wrong here?
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>   

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Zachary Pincus]

It's true -- blindly using allclose isn't a lot better than blindly  
using equality testing. (Though given the choice between blindly  
using one and blindly using the other, I'd still probably vote for  
allclose... it won't get you quantum mechanics, but it'll do fine for  
a lot of other things.)

On the other hand, *properly* using allclose (e.g. setting the  
absolute and expected relative error tolerances) is better than  
properly using equality testing because in many cases there is no  
proper use for equality testing.

Zach

On Feb 21, 2007, at 10:29 AM, Anne Archibald wrote:

> On 21/02/07, Zachary Pincus <[EMAIL PROTECTED]> wrote:
>
>> A corrolary: in general do not two floating-point values for equality
>> -- use something like numpy.allclose. (Exception -- equality is
>> expected if the exact sequence of operations to generate two numbers
>> were identical.)
>
> I really can't agree that blindly using allclose() is a good idea. For
> example, allclose(plancks_constant,0) and the difference leads to
> quantum mechanics... you really have to know how much difference you
> expect and how big your numbers are going to be.
>
> Anne
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[WolfgangZillig]

Anne Archibald schrieb:
> On 21/02/07, WolfgangZillig <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I'm quite new to numpy/scipy so please excuse if my problem is too obvious.
>>
>> example code:
>>
>> import numpy as n
>> print n.sin(n.pi)
>> print n.cos(n.pi/2.0)
>>
>> results in:
>> 1.22460635382e-016
>> 6.12303176911e-017
>>
>> I've expected something around 0. Can anybody explain what I am doing
>> wrong here?
> 
> Well, nothing. It is around zero. Try (without numpy)
 (1.+1e-16)-1.
> 0.0
> That is, for floating-point numbers, 1e-16 is about the fractional
> error you can expect from any calculation, and since pi is of order
> unity, you should expect its representation to have about that big an
> error on it; feed that through sin and you get an error of about the
> same size.
> 
> Or, to see more clearly, try taking (on a pocket calculator, say)
> sin(3.14) (or even sin(pi)). Roundoff error is a basic fact of life in
> numerical computations.
> 
> Anne


Thanks for your answers. I was already aware that it won't be exactly 0 
but it wasn't clear to me that the rounding precision is around 1e-16.

Thanks for your help!
Wolfgang

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Anne Archibald]

On 21/02/07, Zachary Pincus <[EMAIL PROTECTED]> wrote:

> A corrolary: in general do not two floating-point values for equality
> -- use something like numpy.allclose. (Exception -- equality is
> expected if the exact sequence of operations to generate two numbers
> were identical.)

I really can't agree that blindly using allclose() is a good idea. For
example, allclose(plancks_constant,0) and the difference leads to
quantum mechanics... you really have to know how much difference you
expect and how big your numbers are going to be.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Anne Archibald]

On 21/02/07, WolfgangZillig <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm quite new to numpy/scipy so please excuse if my problem is too obvious.
>
> example code:
>
> import numpy as n
> print n.sin(n.pi)
> print n.cos(n.pi/2.0)
>
> results in:
> 1.22460635382e-016
> 6.12303176911e-017
>
> I've expected something around 0. Can anybody explain what I am doing
> wrong here?

Well, nothing. It is around zero. Try (without numpy)
>>> (1.+1e-16)-1.
0.0
That is, for floating-point numbers, 1e-16 is about the fractional
error you can expect from any calculation, and since pi is of order
unity, you should expect its representation to have about that big an
error on it; feed that through sin and you get an error of about the
same size.

Or, to see more clearly, try taking (on a pocket calculator, say)
sin(3.14) (or even sin(pi)). Roundoff error is a basic fact of life in
numerical computations.

Anne
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Zachary Pincus]

Your results are indeed around zero.

 >>> numpy.allclose(0, 1.22460635382e-016)
True

It's not exactly zero because floating point math is in general not  
exact. You'll need to check out a reference about doing floating  
point operations numerically for more details, but in general you  
should not expect exact results due to the limited precision of any  
fixed-width digital representation of floats.

A corrolary: in general do not two floating-point values for equality  
-- use something like numpy.allclose. (Exception -- equality is  
expected if the exact sequence of operations to generate two numbers  
were identical.)

Zach Pincus

Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine

On Feb 21, 2007, at 10:11 AM, WolfgangZillig wrote:

> Hi,
>
> I'm quite new to numpy/scipy so please excuse if my problem is too  
> obvious.
>
> example code:
>
> import numpy as n
> print n.sin(n.pi)
> print n.cos(n.pi/2.0)
>
> results in:
> 1.22460635382e-016
> 6.12303176911e-017
>
> I've expected something around 0. Can anybody explain what I am doing
> wrong here?
>
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Robert Kern]

WolfgangZillig wrote:
> Hi,
> 
> I'm quite new to numpy/scipy so please excuse if my problem is too obvious.
> 
> example code:
> 
> import numpy as n
> print n.sin(n.pi)
> print n.cos(n.pi/2.0)
> 
> results in:
> 1.22460635382e-016
> 6.12303176911e-017
> 
> I've expected something around 0. Can anybody explain what I am doing 
> wrong here?

Nothing. You are getting something around 0 to the limit of double-precision
floating point. numpy.pi cannot be exactly π, but within about 1e-16 of it. That
imprecision carries through the computations.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[Charles R Harris]

On 2/21/07, WolfgangZillig <[EMAIL PROTECTED]> wrote:


Hi,

I'm quite new to numpy/scipy so please excuse if my problem is too
obvious.

example code:

import numpy as n
print n.sin(n.pi)
print n.cos(n.pi/2.0)

results in:
1.22460635382e-016
6.12303176911e-017

I've expected something around 0. Can anybody explain what I am doing
wrong here?



They *are* around zero. You are seeing rounding error, probably both in the
value of pi and the approximations used to evaluate the sin and cos, most
likely some rational min/max fit. I recall teaching PDEs to students who
used Mathematica and they had the same sort of problem because terms
involving sin(pi) didn't go exactly to zero. Made their fourier series not
quite match the text answers. If you want these sort of terms to be exact
you will have to use some sort of symbolic program.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

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

[WolfgangZillig]

Hi,

I'm quite new to numpy/scipy so please excuse if my problem is too obvious.

example code:

import numpy as n
print n.sin(n.pi)
print n.cos(n.pi/2.0)

results in:
1.22460635382e-016
6.12303176911e-017

I've expected something around 0. Can anybody explain what I am doing 
wrong here?

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion