R
Robert Fendt
Hi all,
problem: I have to determine the largest negative float the current
implementation can hold (in a portable way).
The C++ standard just states that floating point properties are
implementation-defined. The 0x draft seems to add
std::numeric_limits<>::lowest() precisely for that reason, since the
lowest representable number is not necessarily the same as -
std::numeric_limits<float>::max() (i.e., -FLT_MAX). But 0x is still
not finished, and I have to deal with C++ 98. So far so bad.
However: ISO C explicitely specifies a floating-point model in which
the sign is a separate factor (and in the annexes, ISO C99 even
enforces that availability of IEEE754 for its float types can be
checked through a preprocessor symbol, which is also helpful). Does
this mean that -(-FLT_MAX)==FLT_MAX, i.e. the negative of FLT_MAX
_exists_, is well-defined and can be round-tripped? If so, is this
true for standard C++ as well (it does provide <cfloat>, after all)?
In that case, I do not really care if the float implementation 'may'
support an even lower number, since I am dealing in symmetric ranges
anyway.
Regards,
Robert
problem: I have to determine the largest negative float the current
implementation can hold (in a portable way).
The C++ standard just states that floating point properties are
implementation-defined. The 0x draft seems to add
std::numeric_limits<>::lowest() precisely for that reason, since the
lowest representable number is not necessarily the same as -
std::numeric_limits<float>::max() (i.e., -FLT_MAX). But 0x is still
not finished, and I have to deal with C++ 98. So far so bad.
However: ISO C explicitely specifies a floating-point model in which
the sign is a separate factor (and in the annexes, ISO C99 even
enforces that availability of IEEE754 for its float types can be
checked through a preprocessor symbol, which is also helpful). Does
this mean that -(-FLT_MAX)==FLT_MAX, i.e. the negative of FLT_MAX
_exists_, is well-defined and can be round-tripped? If so, is this
true for standard C++ as well (it does provide <cfloat>, after all)?
In that case, I do not really care if the float implementation 'may'
support an even lower number, since I am dealing in symmetric ranges
anyway.
Regards,
Robert