what goes wrong with cos(), sin()
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?
On 2/21/07, WolfgangZillig <wollez@gmx.net> 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
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
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
On 21/02/07, Zachary Pincus <zpincus@stanford.edu> 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
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 <zpincus@stanford.edu> 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
Anne Archibald wrote:
On 21/02/07, Zachary Pincus <zpincus@stanford.edu> 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
On 21/02/07, WolfgangZillig <wollez@gmx.net> 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
Anne Archibald schrieb:
On 21/02/07, WolfgangZillig <wollez@gmx.net> 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
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 Chris.Barker@noaa.gov
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
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
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 Chris.Barker@noaa.gov
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
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.00000000000000013634246772254977 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
On 21/02/07, Robert Kern <robert.kern@gmail.com> 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
On 2/21/07, Robert Kern <robert.kern@gmail.com> 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.
<snip> 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
On 2/21/07, Charles R Harris <charlesr.harris@gmail.com> wrote:
On 2/21/07, Robert Kern <robert.kern@gmail.com> 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.
<snip>
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
-- //=][=\\ tim.hochberg@ieee.org
On 2/21/07, Timothy Hochberg <tim.hochberg@ieee.org> wrote:
On 2/21/07, Charles R Harris <charlesr.harris@gmail.com> wrote:
On 2/21/07, Robert Kern < robert.kern@gmail.com> 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.
<snip>
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/<ipython console> 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
On 2/21/07, Charles R Harris <charlesr.harris@gmail.com> wrote:
On 2/21/07, Timothy Hochberg <tim.hochberg@ieee.org> wrote:
On 2/21/07, Charles R Harris < charlesr.harris@gmail.com> wrote:
On 2/21/07, Robert Kern < robert.kern@gmail.com> 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.
<snip>
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/<ipython console>
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
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* <tim.hochberg@ieee.org <mailto:tim.hochberg@ieee.org>> wrote:
On 2/21/07, *Charles R Harris* < charlesr.harris@gmail.com <mailto:charlesr.harris@gmail.com>> wrote:
On 2/21/07, *Robert Kern* < robert.kern@gmail.com <mailto:robert.kern@gmail.com>> 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.
<snip>
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/<ipython console>
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 <http://response.restoration.noaa.gov/emergencyresponse/>
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 "<stdin>", line 1, in <module> TypeError: a float is required N.uint8("4") Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: setting an array element with a sequence. N.uint16("4") Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: setting an array element with a sequence. N.int16("4") Traceback (most recent call last): File "<stdin>", line 1, in <module> 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 Chris.Barker@noaa.gov
On 2/21/07, Christopher Barker <Chris.Barker@noaa.gov> 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
Chris.Barker@noaa.gov _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
-- //=][=\\ tim.hochberg@ieee.org
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, -50000 < e < 50000. AFAIK, most of HP's calculators are like this. -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm@physics.mcmaster.ca
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
participants (10)
-
Anne Archibald -
Charles R Harris -
Christopher Barker -
David Goldsmith -
David L Goldsmith
-
David M. Cooke -
Robert Kern -
Timothy Hochberg -
WolfgangZillig -
Zachary Pincus