Author: Fernando Cacciola
A proposal to extend numeric_limits for consistent range query (Revision 1)
Motivation and Scope
numeric_limits::min()(126.96.36.199) is defined with a meaning which is inconsistent across integer and floating-point types. Specifically, for integer types, it is the minimum finite value whereas for floating point types it is the minimum positive normalized value. The inconsistency here lies in the interpretation of minimum: in the case of integer types, it signifies lowest, while for floating point types, it signifies smallest non-zero.
Though the smallest non-zero value of a floating point type is important for floating point computations, the lowest arithmetic value is important because it indicates the lower bound of the numeric range. In fact, lowest is a concept applicable to any arithmetic type and so is more general.
numeric_limits<T>::min(), the lowest value is given by:
Tis an integer type
Tis a floating-point type
In practice, the inconsistency causes two problems: first, usage of
numeric_limits::min()in generic code requires the code to distinguish if the type is integer or floating point, and to do so using template metaprogramming if performance is important. Second, and more important, it confuses users. A web search for "numeric_limits::min" shows that ever since the Standard was released and up to the present day lots of users get this the wrong way expecting min() to mean lowest.
This proposal suggests to fix this by adding the additional function
Impact On the Standard
The proposal is not to change the meaning of min() (which could break existing code) but to add a new lowest() function that provides the expected meaning consistently.
Proposed Text for the Standard
A. Add to 188.8.131.52 [lib.numeric.limits]:
static T lowest() throw;below
B. Insert in 184.108.40.206 [lib.numeric.limits.members], below
max():static T lowest() throw();
1.For integer types, returns min(); for floating point types, return -max();
All the people in the boost community, particularly those involved in the development of the Boost.NumericConversion library.
Thorsten Ottosen for his help preparing this proposal.
Boost.Numeric Conversion Library, http://www.boost.org/libs/numeric/conversion/doc/index.html, Fernando Cacciola