Re: Maths Constants

From: k.hagan_at_[hidden]
Date: 2001-02-13 04:51:57

<pbristow_at_[hidden]> wrote:
>
> 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?

I think differences in accuracy are inevitable, even if processors
claim to be IEEE. On x86 and 68k, the FPU has 80 bit registers.
Even if you set the operating precision to 64 or 32, it still isn't
entirely equivalent to an FPU that has true 32 or 64-bit wide
registers, such as (amusingly enough) the SSE registers added in
the Pentium 3 and 4, or the registers in a PowerPC or Alpha.
Intel's 64-bit chip has FP registers even wider still. They are
deliberately a couple of bits wider than *any* memory based
floating point type.

In all these cases, the accuracy that you get out depends on how
the compiler balances memory accesses against register pressure.
The standard allows FP calculations to be carried out at "inflated"
precision anyway, for these kinds of reason, so float calculations
may be done at double precision as specified in "classic C".

In such circumstances, I don't think we have the luxury of calling
the extra accuracy "badder", so we'll just have to call it better.

(The main reason why the x86 provides these "load constant"
instructions is to support rounding modes correctly. The most
accurate representation differs if the rounding mode is towards
+/- infinity. In one case we want the closest value below the
constant, and in the other case we want the closest value above it.
No compile-time constant can reproduce this behaviour, and working
it out at run-time is not terribly fast, at least for the "long
double" case! We probably don't care about this. Jens might, in the
context of his boost interval library, where he needs a pi for
argument reduction, if I remember correctly.)

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

I still don't like the namespace pollution that #define causes.
What was the objection to something like...?

   template<class T> struct math_constants /*==namespace*/
   {
      static T e() { return T(2.718...L); }
   };