DBL_MAX,DBL_MIN defined as?

[David Mathog]

What exactly do DBL_MAX and DBL_MIN define? It looks like it is
probably "biggest number that can be represented at a specified
precision" and not "biggest number that can be represented".

There are some differences as the upper/lower limits are approached in
a 32 bit program compiled by gcc ver 4.2.3 like:

gcc -Wall -std=c99 -pedantic -lm -g -O0 -o dmath test_math.c

Such a program prints DBL_MAX, DBL_MIN (from float.h) as:

1.797693e+308 and 2.225074e-308

The upper limit looks about right. When a larger number is entered the
conversion fails,
and precision is maintained right up to that point as in this example
(input value, echo it back)

1e+308
1.000000000000000e+308
1.5e+308
1.500000000000000e+308
1.6e+308
1.600000000000000e+308
1.7e+308
1.700000000000000e+308
1.8e+308
(conversion failed)

However the lower limit seems to be a bit squishy. The number of
correct digits in the mantissa shrinks as the exponent becomes more
negative until the conversion fails outright, but that's much smaller
than DIG_MIN. Unfortunately that leaves room for some (admittedly
tiny) numbers with significant errors to enter a calculation without
warning. Here is a log, number entered, then printed back in %le
format:

2.3e-308
2.300000000000000e-308 <-- so precision is OK down to DIG_MIN
2.3e-309
2.299999999999998e-309 <-- but not below it
2.3e-310
2.299999999999978e-310
2.3e-315
2.300000001942595e-315
2.3e-320
2.299875581391003e-320 <-- error in the 5th digit
2.3e-325
(conversion failed)

Conversion is with:

dtmp=strtod(buffer,&cptr);

Are we really supposed to have to do a
if(dtmp < DIG_MIN){ reject_it(); }

?


Thanks,

David Mathog

 

[Ben Pfaff]

What exactly do DBL_MAX and DBL_MIN define? It looks like it is
probably "biggest number that can be represented at a specified
precision" and not "biggest number that can be represented".

C99 says that DBL_MAX is the maximum representable finite
floating-point number.

C99 says that DBL_MIN is the minimum normalized positive
floating-point number. There may be smaller positive
floating-point numbers, but they are denormals.

However the lower limit seems to be a bit squishy. The number of
correct digits in the mantissa shrinks as the exponent becomes more
negative until the conversion fails outright, but that's much smaller
than DIG_MIN.

DBL_MIN, you mean.

Yes, those are denormals.

Are we really supposed to have to do a
if(dtmp < DIG_MIN){ reject_it(); }

I'm not sure how to interpret the standard's wording in this
area, but if that's what your implementation does then I'd guess
that, yes, you have to.

 

[David Mathog]

I'm not sure how to interpret the standard's wording in this
area, but if that's what your implementation does then I'd guess
that, yes, you have to.

Oops, all negative numbers will fail that test and be rejected. Ah, I
see, use fpclassify() and look for FP_SUBNORMAL. Seems like an odd
design choice for strtod() though. I can only think of a single
instance where I would want it to accept a subnormal value - for
testing what other pieces of code would do if they happened to
generate a subnormal value during a calculation. Even then, why not
set errno when that happens?

Thanks,

David Mathog

 

[Tim Prince]

C99 says that DBL_MAX is the maximum representable finite
floating-point number. of type double

C99 says that DBL_MIN is the minimum normalized positive
floating-point number. of type double
There may be smaller positive doubles
, but they are denormals.

DBL_MIN, you mean.

If your CPU is set to IEEE gradual underflow mode, the smallest non-zero
positive double is DBL_MIN*DBL_EPSILON, and it might be expected to have
1 bit of precision.

Yes, those are denormals.

In abrupt underflow mode, DBL_MIN would be the smallest positive double.
In either case, it's the smallest one for which DBL_MANT_DIG is valid.
Most compilers have a optimization flag which includes the effect of
causing main() to initialize the CPU to abrupt underflow, if the OS
itself doesn't do that.