为什么FLT_MAX和FLT_MIN不是正的和负的无穷大，它们的用途是什么？

Question

Logically speaking, given the nature of floating point values, the maximum and minimum representable values of a float are positive and negative infinity, respectively.

Why, then, are FLT_MAX and FLT_MIN not set to them? I understand that this is "just how the standard called for". But then, what use could FLT_MAX or FLT_MIN have as they currently lie in the middle of the representable numeric range of float ? Other numeric limits have some utility because they make guarantees about comparisons (eg "No INT can test greater than INT_MAX"). Without that kind of guarantee, what use are these float limits at all?

A motivating example for C++:

#include <vector>
#include <limits>

template<typename T>
T find_min(const std::vector<T> &vec)
{
    T result = std::numeric_limits<T>::max();
    for (std::vector<T>::const_iterator p = vec.start() ; p != vec.end() ; ++p)
        if (*p < result) result = *p;
    return result;
}

This code works fine if T is an integral type, but not if it is a floating point type. This is annoying. (Yes yes, the standard library provides min_element , but that is not the point. The point is the pattern .)

Answer 1

FLT_MAX is defined in section 5.2.4.2.2(9) as

maximum representable finite floating-point number

Positive infinity is not finite.

FLT_MIN is defined in section 5.2.4.2.2(10) as

minimum normalized positive floating-point number

Negative infinity is neither normalized nor positive.

Answer 2

The purpose of FLT_MIN / MAX is to tell you what the smallest and largest representable floating-point numbers are. Infinity isn't a number; it's a limit.

what use could FLT_MAX or FLT_MIN have as they currently lie in the middle of the representable numeric range of float?

They do not lie in the middle or the representable range. There is no positive float value x which you can add to FLT_MAX and get a representable number. You will get +INF.

This code works fine if T is an integral type, but not if it is a floating point type. This is annoying. (Yes yes, the standard library provides min_element, but that is not the point. The point is the pattern.)

And how doesn't it "work fine?" It gives you the smallest value. The only situation where it doesn't "work fine" is if the table contains only +INF. And even in that case, it returns an actual number , not an error-code. Which is probably the better option anyway.

Answer 3

I would say the broken pattern you're seeing is only an artifact of poor naming in C, whereas in C++ with numeric_limits and templates, it's an actual semantic flaw that breaks template code that wants to handle both integer and floating point values. Of course you can write a little bit of extra code to test if you have an integer or floating point type (eg if ((T)1/2) /* floating point */ else /* integer */ ) and the problem goes away.

As for why somebody would care about the values FLT_MIN and FLT_MAX give you, they're useful for avoiding underflow and overflow. For example, suppose I need to compute sqrt(x²-1) . This is well-defined for any floating point x greater than or equal to 1, but performing the squaring, subtraction, and square root could easily overflow and render the result meaningless when x is large. One might want to test whether x > FLT_MAX/x and handle this case some other way (such as simply returning x :-).

Answer 4

Unlike integer types, floating-point types are (almost?) universally symmetric about zero, and I think the C floating-point model requires this.

On two's-complement systems (ie, almost all modern systems), INT_MIN is -INT_MAX-1 ; on other systems, it may be -INT_MAX . (Quibble: a two's-complement system can have INT_MIN equal to -INT_MAX if the lowest representable value is treated as a trap representation.) So INT_MIN conveys information that INT_MAX by itself doesn't.

And a macro for the smallest positive value would not be particularly useful; that's just 1.

In floating-point, on the other hand, the negative value with the greatest magnitude is just -FLT_MAX (or -DBL_MAX , or -LDBL_MAX ).

As for why they're not Infinity, there's already a way to represent infinite values (at least in C99): the macro INFINITY . That might cause problems for some C++ applications, but these were defined for C, which doesn't have things like std::numeric_limits<T>::max() .

Furthermore, not all floating-point systems have representations for infinity (or NaN).

If FLT_MAX were INFINITY (on systems that support it), then there would probably need to be another macro for the largest representable real value.