Smallest float different from 0.0?

Mark Dickinson dickinsm at gmail.com
Mon Sep 7 19:33:44 CEST 2009


On Sep 7, 5:08 pm, kj <no.em... at please.post> wrote:
> Hmmm.  This close-to-the-metal IEEE stuff make a "HERE BE DRAGONS!"
> alarms go off in my head...  (What's up with that correction by 1
> to sys.float_info.mant_dig?  Or, probably equivalently, why would
> sys.float_info.min_exp (-1021) be off by 1 relative to log2 of
> sys.float_info.min (-1022)?)

The sys.float_info constants come straight from the standard C
limits defined in float.h.  The C standards choose to describe
floats in the form

  sign * 2**exponent * significand

with 0.5 <= significand < 1.0.  (Well, assuming base 2;  the
actual standard is a bit more general than this;  see e.g.
section 5.2.4.2.2 of C99.)

So from C's point of view, the smallest normal value
comes from the minimum exponent (-1021) together with
the minimum significand (0.5), so it's 2**-1021 * 0.5,
or 2**-1022.  Similarly, the max value is (1-2**-53)*2**1024.

It's a bit unfortunate that the IEEE 754 standard prefers
a different normalization, with the exponent chosen so that
the significand is in [1.0, 2.0).  So where IEEE 754-2008
gives emax as 1023, C gives DBL_MAX_EXP as 1024;  both
describing exactly the same format.

> I suppose that
>
> 2**(sys.float_info.min_exp - sys.float_info.mant_dig)
>
> would also work?

Yes.  This all only works for IEEE 754 binary formats,
though.  Most other floating-point formats you're likely
to meet (IBM hex floats, VAX D and G, Cray floats, etc.)
don't have gradual underflow and subnormals.

--
Mark



More information about the Python-list mailing list