Re: [boost] math constants

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2000-07-26 15:20:01

John Maddock wrote:
> On conforming compilers the problem is that the value is rounded twice -
> once to a long double (on decimal to binary conversion), then again to a
> float.  This double rounding can result in the value being out by 1ulp (I
> think, well at least maybe: I'm not a math expert - it may be 2ulp), and
> the value is no longer the "closest binary representation". 

In general, C++ doesn't say much how floating-point numbers behave, so
we have to argue with "reasonable behaviour" as defined by most
compilers.

Since the standard says that  float <= double <= long double,
we should aim for long double constants.  If double == long double
(on Sun, I think), no further rounding for T == double should occur.
If, however, T < long double, then T usually has several binary digits
less precision than long double (for example, float and double on Intel
x86). 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.

Of course, if the compiler fails to take advantage of all given digits
for the decimal to binary conversion, there is a problem. Hex floats
are allowed in ISO C99, but not in C++ (yet).

>  I think the
> code should be:
> 
> static const T sqrt_two() _THROW0()
> { return 1.41421356237309504880168872420969807857F; }

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.

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.

Jens Maurer