RE: [boost] Math Constants Library formal review results

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-05-17 14:37:43

----- Original Message -----
From: Ed Brey <brey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, May 17, 2001 4:08 PM
Subject: Re: [boost] Math Constants Library formal review results

> 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.
>
All right. You've made a point here.
I realize that if I just add boost::constants::my_constant to my local boost
copy, I am indirectly implying that 'my_constant' is part of the boost
library while it isn't. That is likely to cause portability problems.
Therefore, we need to draw a line somewhere as Matt noted, and in that
respect I preliminary agree with your proposal above.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com