How to workaround the inconsistent definition of numeric_limits::min()?

Question

The numeric_limits traits is supposed to be a general way of obtaining various type infomation, to be able to do things like

template
T min(con         


        

Answer 1

numeric_limits<int>::min returned the lowest negative number, all floating point number types, return the smallest positive number when I tried it with Sun CC & g++.

I guess this is because 'smallest' and 'minimum' mean different things with floating point numbers. It is a bit odd though.

Both Sun CC and g++ produce the same result :

short:min: -32768 max: 32767

int:min: -2147483648 max: 2147483647

unsigned int:min: 0 max: 4294967295

long:min: -2147483648 max: 2147483647

float:min: 1.17549e-38 max: 3.40282e+38

double:min: 2.22507e-308 max: 1.79769e+308

long double:min: 3.3621e-4932 max: 1.18973e+4932

unsigned short:min: 0 max: 65535

unsigned int:min: 0 max: 4294967295

unsigned long:min: 0 max: 429496729

template<typename T>
void showMinMax()
{
    cout << "min: " << numeric_limits<T>::min() << endl;
    cout << "max: " << numeric_limits<T>::max() << endl;
    cout << endl;
}

int main()
{
cout << "short:";
showMinMax<short>()
...etc...etc..

Answer 2

This is an old thread, but there is an updated answer:

C++11 added a lowest() function to std::numeric_limits (See here)

So you can now call std::numeric_limits<double>::lowest() to get the lowest representable negative value.

Answer 3

I'm not sure of the rationale but it is expected behaviour. Well, in the sense that is how Josuttis (and, presumably the standard) describes it!

min(): "Miniumum finite value (minimum normalized value for floating-point types with denormalization)."

As best I can tell if the type is not an integer (numeric_limits<>::is_integer) and has denormalization (numeric_limits<>::has_denorm) min() will return the smallest representable value by that type. Otherwise it will return the smallest value - which may be negative.

For a more consistent interface check out the Boost numeric/conversion library. Specifically the bounds traits class. Here's a snippet:

cout << "lowest float:" << boost::numeric::bounds<float>::lowest();
cout << "lowest int:  " << boost::numeric::bounds<int>::lowest();

You may also find the boost::integer library useful. It brings some of C99's integer support (like int_least16_t) to C++ and can help select the best sized type for you particular need. An example:

boost::uint_t<20>::fast fastest20bits; // fastest unsigned integer that 
                                       // can hold at least 20 bits.
boost::int_max_value_t<100000>::least  // smallest integer that can store
                                       // the value 100000.

I often find that when I need one of boost::numeric/conversion or boost::integer I need them both.

Answer 4

The behaviour of min() isn't all that strange, it returns FLT_MIN, DBL_MIN or INT_MIN (or their respective values), depending on the type you specialize with. So your question should be why FLT_MIN and DBL_MIN are defined differently from INT_MIN.

Unfortunately, I don't know the answer to that latter question.

My suspicion is that it was defined that way for practical purposes. For integer numbers, you're usually concerned with overflow/underflow, where the minimum and maximum value become of interest.

For floating point numbers, there exists a different kind of underflow in that a calculation could result in a value that's larger than zero, but smaller than the smallest representable decimal for that floating point type. Knowing that smallest representable floating point value allows you to work around the issue. See also the Wikipedia article on subnormal/denormal numbers.

Answer 5

A workaround would be

double val = -std::numeric_limits<double>::max();

Of course, this doesn't explain the strange behaviour of numerics_limits::min() which could be a result of the fact that there are different min/max borders for integers (min = -2^n, max = 2^n-1) but not for doubles.

Answer 6

The definition of the smallest value for an empty vector can be argued. If the vector is empty then there is no smallest element.

Prefer to use std::min_element instead:

int main()
{
    std::vector<int> v;
    std::generate_n(std::back_inserter(v), 1000, std::rand);

    std::vector<int>::iterator it  = std::min_element(v.begin(), v.end());
    if (it == v.end())
    {
        std::cout << "There is no smallest element" << std::endl;
    }
    else
    {
        std::cout << "The smallest element is " << *it << std::endl;
    }
}