Some C Floating Point Constants Don't Make Sense

Question

The constants in <float.h> for Apple clang version 12.0.0 (clang-1200.0.32.2) don't seem to make sense.

DBL_MIN_EXP is -1021 and DBL_MAX_EXP is 1024. However, that doesn't match what wikipedia says, "exponents range from −1022 to +1023, ..."

Also DBL_MIN_EXP seems inconsistent with DBL_MIN which is 2.2250738585072014e-308 which is equal to 2⁻¹⁰²² sometimes written as 0x1.0000000000000p-1022. So, we have an exponent smaller than the minimum -1021.

Likewise, DBL_MIN_10_EXP is -307 which doesn't sense given that DBL_MIN has an exponent of e-308.

The double DBL_MAX_EXP value of 1024 overflows when used in real code. For example, ldexp(1.0, 1024) gives inf.

Here's my C code:

#include <float.h>
#include <stdio.h>
#include <math.h>

#define SHOW_DOUBLE(s)   printf("%.17lg \t%s\n", s, #s);
#define SHOW_INT(s)      printf("%d \t%s\n", s, #s);

int
main()
{
    SHOW_DOUBLE(DBL_MAX);
    SHOW_DOUBLE(DBL_MIN);
    SHOW_DOUBLE(DBL_EPSILON);
    SHOW_INT(DBL_MAX_EXP);
    SHOW_INT(DBL_MAX_10_EXP);
    SHOW_INT(DBL_MIN_EXP);
    SHOW_INT(DBL_MIN_10_EXP);
    SHOW_INT(DBL_DIG);
    SHOW_INT(DBL_MANT_DIG);
    SHOW_INT(FLT_RADIX);
    SHOW_INT(FLT_ROUNDS);
    printf("%lf\n", ldexp(1.0, 1024));
    return 0;
}

And here is the output:

1.7976931348623157e+308 DBL_MAX
2.2250738585072014e-308 DBL_MIN
2.2204460492503131e-16  DBL_EPSILON
1024                    DBL_MAX_EXP
308                     DBL_MAX_10_EXP
-1021                   DBL_MIN_EXP
-307                    DBL_MIN_10_EXP
15                      DBL_DIG
53                      DBL_MANT_DIG
2                       FLT_RADIX
1                       FLT_ROUNDS
inf

have you compared with float.h file from other systems? I have the exact same result for gcc on Windows — Jean-François Fabre, Oct 16 '20 at 20:29
Well, from the C standard: *minimum negative integer such that FLT_RADIX raised to **one less** than that power is a normalized floating-point number, emin* — Eugene Sh., Oct 16 '20 at 20:33
for max: /* Maximum int x such that FLT_RADIX**(x-1) is a representable float, emax. */ — Jean-François Fabre, Oct 16 '20 at 20:33

score 9 · Answer 1 · answered Oct 16 '20 at 20:34

9

The off-by-one is part of the spec. From 5.2.4.2.2 Characteristics of floating types <float.h>, ¶11,

...

minimum negative integer such that FLT_RADIX raised to one less than that power is a normalized floating-point number, emin

FLT_MIN_EXP

DBL_MIN_EXP

LDBL_MIN_EXP

...

maximum integer such that FLT_RADIX raised to one less than that power is a representable finite floating-point number, emax

FLT_MAX_EXP

DBL_MAX_EXP

LDBL_MAX_EXP

Emphasis on one less than is mine.

answered Oct 16 '20 at 20:34

R.. GitHub STOP HELPING ICE

208,859
35
376
711

2

And the "one less than" makes sense when you understand that these two are expressing properties associated with C's model for representing floating-point numbers (which appears at the beginning of the referenced section of the standard), not directly the properties of extreme numbers themselves. – John Bollinger Oct 16 '20 at 20:44
@JohnBollinger: Could you clarify how that makes sense? – R.. GitHub STOP HELPING ICE Oct 17 '20 at 20:12
The floating-point model represents numbers as (*sign*) * (`FLT_RADIX` ^ *exponent*) * (*fraction*), where *fraction* is between 0 (inclusive) and 1 (exclusive) and *sign* is either 1 or -1. The \*_MAX_EXP and \*_MIN_EXP are type-specific maximum and minimum values for the *exponent* parameter in that formula, and as such, they are pretty natural. The definitions you quoted from the standard express them in terms of the resulting floating-point values instead of the in terms of the model, which is that description might seem surprising. – John Bollinger Oct 18 '20 at 00:08
@JohnBollinger: Ah, so because the "fraction" is in [0,1) (really [0.5,1) if you're assuming normalization) rather than [1,2) as in normal conventions. – R.. GitHub STOP HELPING ICE Oct 18 '20 at 00:55
Yes, that's it exactly. – John Bollinger Oct 18 '20 at 12:26

Géry Ogam · Answer 2 · 2021-02-13T10:39:15.810

I asked myself the same question and realized that this stems from the fact that IEEE 754 and C use two different normalized forms:

IEEE 754 uses a significand between 1 (inclusive) and 2 (exclusive) for normal numbers:

x = sign × significand × 2^exponent, encoded as S|E|F where sign = (−1)^S; significand =

1.F if E_min ≤ E ≤ E_max (normal number),

0 if E = E_min − 1 and F = 0 (zero),

0.F if E = E_min − 1 and F ≠ 0 (subnormal number),

∞ if E = E_max + 1 and F = 0 (infinity),

NaN if E = E_max + 1 and F ≠ 0 (not a number);

exponent = max(E, E_min) − exponent bias.

C uses a significand′ between 0.5 (inclusive) and 1 (exclusive) for normal numbers:

x = sign′ × significand′ × 2^exponent′, encoded as S|E|F where sign′ = (−1)^S; significand′ =

0.1F if E_min ≤ E ≤ E_max (normal number),

0 if E = E_min − 1 and F = 0 (zero),

0.0F if E = E_min − 1 and F ≠ 0 (subnormal number),

∞ if E = E_max + 1 and F = 0 (infinity),

NaN if E = E_max + 1 and F ≠ 0 (not a number);

exponent′ = max(E + 1, E_min + 1) − exponent bias.

Since x = sign × significand × 2^exponent = sign′ × significand′ × 2^exponent′, the following relations between the IEEE 754 normalized form and the C normalized form hold:

sign′ = sign;
significand′ = significand/2;
exponent′ = exponent + 1.

In particular, in binary64 format that is why exponent_min = −1022 in IEEE 754 normalized form and exponent′_min = −1021 in C normalized form (DBL_MIN_EXP), and exponent_max = 1023 in IEEE 754 normalized form and exponent′_max = 1024 in C normalized form (DBL_MAX_EXP).

In Python:

the IEEE 754 normalized significand and exponent can be extracted with:

math.ldexp(x, -math.floor(math.log2(x))), math.floor(math.log2(x))

the C normalized significand′ and exponent′ can be extracted with:

math.frexp(x)

For instance:

>>> import math
>>> x = 12
>>> math.ldexp(x, -math.floor(math.log2(x))), math.floor(math.log2(x))
(1.5, 3)
>>> math.frexp(12)
(0.75, 4)

Some C Floating Point Constants Don't Make Sense

2 Answers2