Function std::numeric_limits<T>::max()
returns the largest finite value that can be represented by the type T.
If there is no such value (and numeric_limits<T>::bounded
is false) then returns T().

For built-in types there is usually a corresponding MACRO value TYPE_MAX,
where TYPE is CHAR, INT, FLOAT etc.

Other types, including those provided by a typedef, for example INT64_T_MAX for int64_t,
may provide a macro definition.

To cater for situations where no numeric_limits
specialization is available (for example because the precision of the type
varies at runtime), packaged versions of this (and other functions) are
provided using

Function std::numeric_limits<T>::min()
returns the minimum finite value that can be represented by the type T.

For built-in types there is usually a corresponding MACRO value TYPE_MIN,
where TYPE is CHAR, INT, FLOAT etc.

Other types, including those provided by a typedef, for example INT64_T_MIN for int64_t,
may provide a macro definition.

For floating-point types, it is more fully defined as the minimum
positive normalized value.

See std::numeric_limits<T>::denorm_min()
for the smallest denormalized value, provided

std::numeric_limits<T>::has_denorm==std::denorm_present

To cater for situations where no numeric_limits
specialization is available (for example because the precision of the type
varies at runtime), packaged versions of this (and other functions) are
provided using

Function std::numeric_limits<T>::round_error()
returns the maximum error (in units of ULP)
that can be caused by any basic arithmetic operation.

round_style==std::round_indeterminate;

The rounding style is indeterminable at compile time.

For floating-point types, when rounding is to nearest, only half a bit
is lost by rounding, and round_error==0.5.
In contrast when rounding is towards zero, or plus/minus infinity, we can
loose up to one bit from rounding, and round_error==1.

For integer types, rounding always to zero, so at worst almost one bit
can be rounded, so round_error==1.

round_error()
can be used with std::numeric_limits<T>::epsilon()
to estimate the maximum potential error caused by rounding. For typical
floating-point types, round_error()=1/2, so half
epsilon is the maximum potential error.

To achieve greater portability over platform and floating-point type, Boost.Math
and Boost.Multiprecion provide a package of functions that 'do something
sensible' if the standard numeric_limits
is not available. To use these #include<boost/math/tools/precision.hpp>.

For floating-point types only, for which std::numeric_limits<T>::has_infinity==true,
function std::numeric_limits<T>::infinity()
provides an implementation-defined representation for ∞.

The 'representation' is a particular bit pattern reserved for infinity.
For IEEE754 system (for which std::numeric_limits<T>::is_iec559==true)
positive
and negative infinity are assigned bit patterns for all defined
floating-point types.

Confusingly, the string resulting from outputting this representation,
is also implementation-defined. And the string that can be input to generate
the representation is also implementation-defined.

For example, the output is 1.#INF
on Microsoft systems, but inf
on most *nix platforms.

This implementation-defined-ness has hampered use of infinity (and NaNs)
but Boost.Math and Boost.Multiprecision work hard to provide a sensible
representation for all floating-point
types, not just the built-in types, which with the use of suitable facets
to define the input and output strings, makes it possible to use these
useful features portably and including Boost.Serialization.

For floating-point types only, for which std::numeric_limits<T>::has_quiet_NaN==true,
function std::numeric_limits<T>::quiet_NaN()
provides an implementation-defined representation for NaN.

NaNs are values to
indicate that the result of an assignment or computation is meaningless.
A typical example is 0/0 but there are many others.

NaNs may also be used, to represent missing values: for example, these
could, by convention, be ignored in calculations of statistics like means.

Many of the problems with a representation for Not-A-Number
has hampered portable use, similar to those with infinity.

NaN can be used with binary multiprecision types like cpp_bin_float_quad:

usingboost::multiprecision::cpp_bin_float_quad;if(std::numeric_limits<cpp_bin_float_quad>::has_quiet_NaN==true){cpp_bin_float_quadtolerance=3*std::numeric_limits<cpp_bin_float_quad>::epsilon();cpp_bin_float_quadNaN=std::numeric_limits<cpp_bin_float_quad>::quiet_NaN();std::cout<<"cpp_bin_float_quad NaN is "<<NaN<<std::endl;// cpp_bin_float_quad NaN is nancpp_bin_float_quadexpected=NaN;cpp_bin_float_quadcalculated=2*NaN;// Comparisons of NaN's always fail:boolb=expected==calculated;std::cout<<b<<std::endl;BOOST_CHECK_NE(expected,expected);BOOST_CHECK_NE(expected,calculated);}else{std::cout<<"Type "<<typeid(cpp_bin_float_quad).name()<<" does not have NaNs!"<<std::endl;}

But using Boost.Math and suitable facets can permit portable use of both
NaNs and positive and negative infinity.

For floating-point types only, for which std::numeric_limits<T>::has_signaling_NaN==true,
function std::numeric_limits<T>::signaling_NaN()
provides an implementation-defined representation for NaN that causes a
hardware trap. It should be noted however, that at least one implementation
of this function causes a hardware trap to be triggered simply by calling
std::numeric_limits<T>::signaling_NaN(),
and not only by using the value returned.