Looking for the greatest negative float value

Dan Bishop danb_83 at yahoo.com
Fri Jun 13 01:53:08 CEST 2003


bokr at oz.net (Bengt Richter) wrote in message news:<bca8na$4b6$0 at 216.39.172.122>...
> On 11 Jun 2003 22:01:43 -0700, danb_83 at yahoo.com (Dan Bishop) wrote:
> 
> >mwilson at the-wire.com (Mel Wilson) wrote in message news:<Yr55+ks/KTSM089yn at the-wire.com>...
> >> In article <bc7lvb$gm3$1 at news-reader12.wanadoo.fr>,
> >> "Gilles Lenfant" <glenfant at NOSPAM.bigfoot.com> wrote:
> >> >Hi,
> >> >
> >> >I need the same as...
> >> >
> >> >import sys
> >> >negmaxint = - sys.maxint -1
> >> >
> >> >... but for float data
>  [snip]
> >> -1.7976931348623157e+308
> >> 
> >> and that last number seems credible.
> >
> >Close.  The exact value, per the IEEE 754 standard, is -(2 ** 1024 - 2
> >** 972), or -1.7976931348623155e+308.  How did you get a *higher*
> >magnitude?
> 
> Because UIAM the IEEE 754 standard allows 53 significant bits, not 52.
> Note that your constant can be rewritten:
> 
>  >>> -(2**1024 - 2**972) == -(2**52 - 1)*2**972
>  1
> 
> Yet 2**53-1 is eactly representable in a floating point double:
> 
>  >>> float(2**53-1)
>  9007199254740991.0

Ah!  It's so much clearer when you write it that way.

I knew that doubles had 53 bits (and therefore, epsilon=2**-52), and
that maxfloat was slightly less than 2 ** 1024 (because 2 ** 1024's
bit pattern is used for infinity), and had erroneously calculated
maxfloat as

(1 - epsilon) * 2 ** 1024

instead of the correct

(1 + 1/2 + 1/4 + ... + epsilon) * 2 ** 1023
= (2 - epsilon) * 2 ** 1023
= (1 - epsilon/2) * 2 ** 1024

And sure enough, printf("%.17g", 0x7FEFFFFFFFFFFFFFLL) in C (plus
enough casting to bypass compiler warnings) prints
"1.7976931348623157e+308".




More information about the Python-list mailing list