Looking for the greatest negative float value
Dan Bishop
danb_83 at yahoo.com
Thu Jun 12 19:53:08 EDT 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