[Numpy-discussion] Floating point question
I recently discovered that for 8 byte floating point numbers, my fortran compilers (gfortran 4.2 and ifort 11.0) on an OS X core 2 duo machine believe the smallest number 2.220507...E-308. I presume that my C compilers have similar results. I then discovered that the smallest floating point number in python 2.5 is 4.9065...E-324. I have been using numpy to generate data, saving it with savetxt, and then reading it in as ASCII into my fortran code. Recently, it crapped out on something because it didn't like reading it a number that small, though it is apparently perfectly acceptable to python. My two questions are: 1. What is the best way to handle this? Is it just to add a filter of the form u = u * ( np.abs(u) 2.3 e-308) 2. What gives? What's the origin of this (perceived) inconsistency in floating points across languages within the same platform? I recognize that this isn't specific to Scipy/Numpy, but thought someone here might have the answer. -gideon ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating point question
On Mon, Mar 2, 2009 at 14:37, Gideon Simpson simp...@math.toronto.edu wrote: I recently discovered that for 8 byte floating point numbers, my fortran compilers (gfortran 4.2 and ifort 11.0) on an OS X core 2 duo machine believe the smallest number 2.220507...E-308. I presume that my C compilers have similar results. I then discovered that the smallest floating point number in python 2.5 is 4.9065...E-324. I have been using numpy to generate data, saving it with savetxt, and then reading it in as ASCII into my fortran code. Recently, it crapped out on something because it didn't like reading it a number that small, though it is apparently perfectly acceptable to python. My two questions are: 1. What is the best way to handle this? Is it just to add a filter of the form u = u * ( np.abs(u) 2.3 e-308) You can get the precise value from finfo: In [2]: from numpy import finfo In [3]: f = finfo(float64) In [4]: f.tiny Out[4]: array(2.2250738585072014e-308) I'd probably do something like this: u[abs(u) f.tiny] = 0.0 2. What gives? What's the origin of this (perceived) inconsistency in floating points across languages within the same platform? 4.9065...E-324 is a denormalized float. http://en.wikipedia.org/wiki/Denormal_number -- 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] Floating point question
On Mon, 2 Mar 2009 15:37:33 -0500, Gideon Simpson wrote: My two questions are: 1. What is the best way to handle this? Is it just to add a filter of the form u = u * ( np.abs(u) 2.3 e-308) 2. What gives? What's the origin of this (perceived) inconsistency in floating points across languages within the same platform? how are you calculating fmin? numpy has a built-in function that will tell you this information: numpy.finfo( numpy.float ).min -1.7976931348623157e+308 hopefully this helps shed some light on your questions. regards, mike ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating point question
On Mar 2, 2009, at 4:00 PM, Michael S. Gilbert wrote: how are you calculating fmin? numpy has a built-in function that will tell you this information: numpy.finfo( numpy.float ).min -1.7976931348623157e+308 hopefully this helps shed some light on your questions. regards, mike When I first discovered this, I was computing: numpy.exp(-x**2) If you try x = 26.7, you'll get 2.4877503498797906e-310 I then confirmed this by dividing 1. by 2. until python decided the answer was 0.0 -gideon ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Floating point question
On Mon, Mar 2, 2009 at 15:00, Michael S. Gilbert michael.s.gilb...@gmail.com wrote: On Mon, 2 Mar 2009 15:37:33 -0500, Gideon Simpson wrote: My two questions are: 1. What is the best way to handle this? Is it just to add a filter of the form u = u * ( np.abs(u) 2.3 e-308) 2. What gives? What's the origin of this (perceived) inconsistency in floating points across languages within the same platform? how are you calculating fmin? numpy has a built-in function that will tell you this information: numpy.finfo( numpy.float ).min -1.7976931348623157e+308 hopefully this helps shed some light on your questions. That's the most-negative representable float, but it is not the smallest-positive (normalized) float (.tiny), which is what he needs to work with. -- 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] Floating point question
On 02/03/2009, Gideon Simpson simp...@math.toronto.edu wrote: I recently discovered that for 8 byte floating point numbers, my fortran compilers (gfortran 4.2 and ifort 11.0) on an OS X core 2 duo machine believe the smallest number 2.220507...E-308. I presume that my C compilers have similar results. I then discovered that the smallest floating point number in python 2.5 is 4.9065...E-324. I have been using numpy to generate data, saving it with savetxt, and then reading it in as ASCII into my fortran code. Recently, it crapped out on something because it didn't like reading it a number that small, though it is apparently perfectly acceptable to python. My two questions are: 1. What is the best way to handle this? Is it just to add a filter of the form u = u * ( np.abs(u) 2.3 e-308) 2. What gives? What's the origin of this (perceived) inconsistency in floating points across languages within the same platform? I recognize that this isn't specific to Scipy/Numpy, but thought someone here might have the answer. What's happening is that numbers like 1e-310 are represented by denormals. If we use base 10 to explain, suppose that floating point numbers could only have five digits of mantissa and two digits of exponent: 1.3000 e 00 2.1000 e-35 1. e-99 Now what to do if you divide that last number in half? You can write it as: 0.5000 e-99 But this is a bit of an anomaly: unlike all normal floating-point numbers, it has a leading zero, and there are only four digits of information in the mantissa. In binary it's even more of an anomaly, since in binary you can take advantage of the fact that all normal mantissas start with one by not bothering to store the one. But it turns out that implementing denormals is useful to provide graceful degradation as numbers underflow, so it's in IEEE. It appears that some FORTRAN implementations cannot handle denormals, which is giving you trouble. It's usually fairly safe to simply replace all denormals by zero. Anne ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
