
Boost : 
From: Gabriel Dos Reis (Gabriel.DosReis_at_[hidden])
Date: 20001019 15:54:27
"David Abrahams" <abrahams_at_[hidden]> writes:
 How can we determine the minimum representable value of a builtin type?

 18.2.1.2 numeric_limits members
 static T min() throw();
 1 Minimum finite value. 181)
 2 For floating types with denormalization, returns the minimum positive
 normalized value.
 3 Meaningful for all specializations in which is_bounded != false, or
 is_bounded == false && is_signed == false.

 Is it guaranteed that the minimum representable value for floating types
 with denormalization is numeric_limits<T>::max()?
Yes. As a general rule, floating point types are symmetric
(i.e. according to LIA).
 If not, I think we have a defect.

 If so, the rules are complicated, but it should be possible to follow them.
Actually, the rules are simple and they should not be hard to follow..
 To follow rule #2, we need to determine if the type has denormalization.
 But:

 18.2.1.2 numeric_limits members 18 Language support library
 static const float_denorm_style has_denorm;
 40 denorm_present if the type allows denormalized values (variable number of
 exponent bits) 195) , denorm_absent if the type does not allow denormalized
 values, and denorm_indeterminate if it is indeterminate at compile time
 whether the type allows denormalized values.

 What if has_denorm is denorm_indeterminate? Maybe the answer is:

 numeric_limits<T>::is_signed && numeric_limits<T>::min() >= 0
 ? numeric_limits<T>::max() : numeric_limits<T>::min()
If the system is conforming to LIA then the floating point values set is
symmetric because LIA's model is signmagnitude.
For nonLIA system (actually, only systems using radiccomplement
representation should exhibit that behaviour) there is a notion of
mostnegative value which is quite distinct from what one calls min()
in case of floating point values.
Yes, the terminology is quite confusing, but I weren't there when
LIA1 was adopted as an international standard.
 Gaby
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk