Boost logo

Boost :

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-07-26 06:44:25


>[PAB] Probably best, though won't this mean that user defined types
always have to be specialised,
when they might rely on conversion to double?<

You mean conversion from double? I guess maybe that would work, but
currently quite a few of the methods are unimplemented. Most current
traits classes (for example numeric_limits char_traits etc don't provide
default implementations.

>[PAB] Since there are so many sig figs, surely should get the nearest
>possible representation in a long double?

In the long double yes, but when that gets rounded again to a float (or
double) the result may not be the nearest representation.

Imagine that float has 3 binary digits of precision, and long double 6
digits, and that the actual number is exactly:


rounded to our imaginary float type the nearest representation is 1.01
rounded to our imaginary long double type the nearest representation is
and when this gets rounded again to a float (by rounding ties to the
nearest even number) the result is 1.10 ... which isn't correct.

Whether this situation happens in fact to the constants in the header I
don't know (it requires a particular combination of digits for double
rounding to be a problem), but it seems sensible to avoid the problem in
the first place.

BTW, in case you are wondering why this matters - imagine that we have set
the hardware fpu to use float precision - in this case it's important that
the number is stored as the nearest float representation, and not stored as
a long double as this will get rounded again when loaded onto the stack -
and not necessarily to the correct value.

>[PAB] Not too sympathetic to dodgy compilers here!
>Surely the above is strictly correct, and should not avoid any warnings.

Actually, my point was that these "dodgy" compilers may result in a more
correct value being loaded on the fpu stack, than those that enforce
rounding to float.

- John.

Boost list run by bdawes at, gregod at, cpdaniel at, john at