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