Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #3819 > unrolled thread

DBL_MAX,DBL_MIN defined as?

Back to article view | Back to comp.lang.c

Contents

  DBL_MAX,DBL_MIN defined as? David Mathog <dmathog@gmail.com> - 2011-05-12 10:42 -0700
    Re: DBL_MAX,DBL_MIN defined as? blp@cs.stanford.edu (Ben Pfaff) - 2011-05-12 10:53 -0700
      Re: DBL_MAX,DBL_MIN defined as? David Mathog <dmathog@gmail.com> - 2011-05-12 11:19 -0700
      Re: DBL_MAX,DBL_MIN defined as? Tim Prince <tprince@computer.org> - 2011-05-12 14:55 -0400

#3819 — DBL_MAX,DBL_MIN defined as?

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

[toc] | [next] | [standalone]

#3821

David Mathog <dmathog@gmail.com> writes:

> 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.
-- 
"Programmers have the right to be ignorant of many details of your code
 and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_

[toc] | [prev] | [next] | [standalone]

#3823

On May 12, 10:53 am, b...@cs.stanford.edu (Ben Pfaff) wrote:
> David Mathog <dmat...@gmail.com> writes:

> > 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.

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

[toc] | [prev] | [next] | [standalone]

#3824

On 5/12/2011 1:53 PM, Ben Pfaff wrote:
> David Mathog<dmathog@gmail.com>  writes:
>
>> 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.
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.
>
>> 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.
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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web