RE: [boost] Re: Math Constants

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-02-12 15:26:43

> -----Original Message-----
> From: k.hagan_at_[hidden] [mailto:k.hagan_at_[hidden]]
> Sent: Monday, February 12, 2001 2:06 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Math Constants
>
>
> On the subject of providing constants in float, double and long
> double flavours...
>
> 1 x86 family processors have built-in constants for pi and several
>   logarithms which are accurate to 66 bits. (This is 2-bits more
>   than a register.) A compiler might provide
>
>     #define PI __pi__
>
>   where __pi__  tells the code generator to use a fldpi instruction
>   rather than loading a value from memory. Does the desirability of
>   this implementation option restrict our choice of syntax, or can
>   compilers work equally happily with
>
>     namespace math_constants {
>       inline long double pi() { return __pi__; }
>     }
>

Since the constants #defined are deliberately 'over-accurate'
(having 2 decimal bits more than necessary) but I do not think that
these will be used to fill the two extra guard and sticky bits.

So using builtin constants might provide a more accurate result,
but one that is not as portable (that may be different from other
processors).
So builtin pi, e ... is better, but maybe also badder?

So I propose leaving the builtin constants to those who really need them.
(In any case there are only a small number compared to my collection).

> 2 The same processors also typically have no loss in performance
>   if asked to evaluate expressions at full precision instead of a
>   more reduced precision. If a compiler vendor used the same over-
>   precise value for all three common floating point types, perhaps
>   using the "__pi__" trick for all three, would this conform to our
>   expectations?

I think the 'extra' accuracy only applies to double (long double
should really involve MORE than 63 bits - though some  like MS (many?)
compilers do not really implement long double.

I think float (if 32 bits) will give the same results whatever.

In summary, I think that there are tradeoffs between Standard portability
giving identical results on all processors, and getting the most accurate
answer.

This is one reason for providing the constants in crude pre-processor
#define
form for all possible uses, and then providing a C++ representation which
should be as portable as
possible for the Standard. (40 of 50 decimal digits would be ideal but
these seem t be compilers that choke above about 35, so since this (106
bits) enough
for almost all purposes now, we will compromise.

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
[phone]
mailto: pbristow_at_[hidden]