Re: [boost] Math Constants Library formal review results

From: Ed Brey (brey_at_[hidden])
Date: 2001-05-17 14:08:02

From: "Paul A. Bristow" <pbristow_at_[hidden]>
>
> 2  Experiments show that precision gains are from zero,
> usually a least significant bit or two, but for functions
> like sqrt, sin, atan, and most of all pow, up the about 32 bits.
> I feel this is worth having with the convenience of NOT defining
> and entering constants.  And portability is very likely to be better.

As Matt elaborated in a separate posting, we can never hope to predefine
all the constants the user will want, and so the interface will always
seem incomplete.  However, as you point out, there can be a significant
advantage to predefining common constants, even if they could be defined
by the user with minimal code anyway, such as sqrt(2).  I view such
predefined constants as a kind of valuable evil, a workaround for
imperfect compilers (a perfect compiler would detect that sqrt(2) can be
computed at compile time and use NTL or the like to do the math).  It is
desirable to define as few compiler workarounds as are reasonable
required, which leads me to see three groupings of constants:

Not easily derivable: e.g. pi, e
Easily derivable, but much precision lost: sqrt(2), ln(2)
Easily derivable, with little precision lost: 0, 1, 1/2, 1/3, ln(2)/2

IMHO, the library should include the first two categories, but not the
third.  Note that ln(2)/2 really covered both the second and third
category, but since given a ln_2 constant in the library, the user can
easily obtain a high-precision ln_2/2 himself, and so there is little in
having this in the library.

From: "Fernando Cacciola" <fcacciola_at_[hidden]>
> But I note that my proposition allows that borderline to be drawn
> *naturally* (inherently unlimited set of constants or limited
> time/space/resources), not arbitrarily by design.

Such an approach is likely to cause name conflicts as subsequent
revisions of the math library are released.  Furthermore, it is likely
that end user code would conflict with other end user code.  The boost
namespace needs to be populated by a centralized entity to avoid
conflicts.