Re: [boost] math constants

From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-07-27 06:18:18

Jens,

> Thus, the additional rounding from long double to float will
>result in the same (binary) value than if the original (decimal)
>constant would have been interpreted as a float in the first place.

No it doesn't - it may do - but it doesn't have to.  The example I posted
in another message was:

"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."

>This would result in float precision for T == double as well, which
>is unacceptable.
>
>The idea of the template approach was that all the boring digits
>of the constants have to be put into the header file only once.
>We can always have three different specializations (float, double,
>long double) of the math_const<> template, but this is ugly.

I intended that the float specialisation use "3.14F", the double
specialisation "3.14" and the long double specialisation "3.14L", note that
the version of the header in the vault already has separate specialisations
for each type, I was objecting to the fact that the float specialisation
was using long constants.  Anyway enough, I'm sounding like a broken record
:-)

>Summary:  Give all constants as long double, with sufficient digits
>to fill about 100 bits of binary mantissa (the largest "long double"
>types nowadays in use are 128 bit including the exponent, I think).
>We can always add more digits later, should the need arise.

For the long double specialisations yes we should have enough digits for
128-bit representations (anyone know how many that would be?), I can't
imagine longer representations than that.  If you want to define all the
digits in one place then we could use a macro, and then use ## to paste the
appropriate suffix on in each specialiation.

- John.