RE: [boost] math constants

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

Paul,

>[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:

1.01011110

rounded to our imaginary float type the nearest representation is 1.01
rounded to our imaginary long double type the nearest representation is
1.01100
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.