Number of significand bits in long double?

[Chuck Swiger]

Steve Kargl wrote:
> Can someone confirm or refute that the long double type
> has 53 bits in its significand on i386?  Which header 
> file in /usr/include provides this info?

/usr/include/float.h ...?

You may wish to examine the enquire.c program from:

http://homepages.cwi.nl/~steven/enquire.html

...which has been bundled with GCC and maybe other things, too.
On a FreeBSD/i386 system using a P3 CPU:

PROPERTIES OF DOUBLE
Base = 2
Significant base digits = 53 (= at least 15 decimal digits)
Arithmetic rounds towards nearest
    Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -53
Smallest x such that 1.0-x != 1.0 = 5.5511151231257839e-17
Smallest x such that 1.0+base**x != 1.0 = -52
Smallest x such that 1.0+x != 1.0 = 1.1102230246251568e-16
(Above number + 1.0) - 1.0 = 2.2204460492503131e-16
Number of bits used for exponent = 11
Minimum normalised exponent = -1022
Minimum normalised positive number = 2.2250738585072014e-308
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 4.9406564584124654e-324
Maximum exponent = 1024
Maximum number = 1.7976931348623157e+308
Overflow doesn't seem to generate a trap
There is an 'infinite' value
Divide by zero doesn't generate a trap
Arithmetic uses a hidden bit
It looks like double length IEEE format

PROPERTIES OF LONG DOUBLE
Base = 2
Significant base digits = 53 (= at least 15 decimal digits)
Arithmetic rounds towards nearest
    Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -53
Smallest x such that 1.0-x != 1.0 = 5.5511151231257839e-17
Smallest x such that 1.0+base**x != 1.0 = -52
Smallest x such that 1.0+x != 1.0 = 1.1102230246251568e-16
(Above number + 1.0) - 1.0 = 2.2204460492503131e-16
Number of bits used for exponent = 15
Minimum normalised exponent = -16382
Minimum normalised positive number = 0.0000000000000000e+00

*** WARNING: Possibly bad output from printf above
     expected value around 3.3621031431121065e-4932, bit pattern:
     00000000 00000000 00000000 00000000 00000000 00000000 00000000 10000000 
00000001 00000000 00001111 00101000
     sscanf gave           0.0000000000000000e+00, bit pattern:
     00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000101 00001000
     difference= 0.0000000000000000e+00

The smallest numbers are not kept normalised
Smallest unnormalised positive number = 0.0000000000000000e+00

*** WARNING: Possibly bad output from printf above
     expected value around 7.4653686412953384e-4948, bit pattern:
     00000000 00001000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00001111 00101000
     sscanf gave           0.0000000000000000e+00, bit pattern:
     00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
00000000 00000000 00000101 00001000
     difference= 0.0000000000000000e+00

Maximum exponent = 16384
Maximum number = Inf

*** WARNING: Possibly bad output from printf above
     expected value around 1.1897314953572353e4932, bit pattern:
     00000000 11111000 11111111 11111111 11111111 11111111 11111111 11111111 
11111110 01111111 00001111 00101000
     sscanf gave           0.0000000000000000e+00, bit pattern:
     10101010 00011110 00001010 00101000 00000001 00000000 00000000 00000000 
00000000 00000000 00000101 00001000
     difference= Inf

Overflow doesn't seem to generate a trap
There is an 'infinite' value
Divide by zero doesn't generate a trap
Only 68 of the 96 bits of a long double are actually used
It doesn't look like IEEE format

Float expressions are evaluated in double precision
Double expressions are evaluated in double precision
Long double expressions are evaluated in double precision

-- 
-Chuck