Date: 08 Apr 1993 14:29:48 +1100
From: Bill Metzenthen <APM233M AT vaxc DOT cc DOT monash DOT edu DOT au>
Subject: Re: Bug in floating point constants
To: djgpp AT sun DOT soe DOT clarkson DOT edu

Cameron Davidson "cjd AT brb DOT dmt DOT csiro DOT au" writes:

>Richard Stallman's reply:
>>  Is there any reason to think this bug is in GCC?
>>  I would expect it is in the C library that you are using.
>>  However, you are in luck: the next version of GCC will
>>  come with its own floating point conversion code, which
>>  ought to be fully accurate.

Hmm, I suspected that this was the case. A fix for this type of
problem is probably easier under Linux because gcc is linked with a
jump-table dll there.

>It is a bit messier than I noted before:
>as the exponent increases, an increasing number of the least significant
>bits of the mantissa are not set reliably. By the time the exponent is
>around 270-300 (decimal) 4 bits are unreliable.

It may be that the Linux libs have better conversion routines; here
are a few more results for Linux gcc 2.3.3:

There are three lines per number this time. The first line is the bit
pattern, the second is the printf() result for plain "%g" format, and
the third line gives the error and the number of bits precision that
this represents. In each case the number is the closest possible to
the nominal value.


d[5] = 7e37e43c 8800759c
1e+300
error = 5.3e-17,  54.080329 bits
d[6] = 7e6ddd4b aa009303
1e+301
error = 5.3e-17,  54.080329 bits
d[7] = 7ea2aa4f 4a405be2
1e+302
error = 7.6e-17,  53.541151 bits
d[8] = 7ed754e3 1cd072da
1e+303
error = 1.6e-19,  62.422734 bits
d[9] = 7f0d2a1b e4048f90
1e+304
error = -6.1e-17,  53.869978 bits
d[10] = 7f423a51 6e82d9ba
1e+305
error = -6.1e-17,  53.869978 bits
d[11] = 7f76c8e5 ca239029
1e+306
error = 1.7e-17,  55.689022 bits
d[12] = 7fac7b1f 3cac7433
1e+307
error = -1.4e-17,  55.990555 bits
d[13] = 7fe1ccf3 85ebc8a0
1e+308
error = 1.1e-17,  56.338023 bits



--Bill