RE: [boost] Math Constants Library formal review results

From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2001-05-18 04:19:20

I've read these arguments with interest and they have merit.

I agree we don't want thousands of constants,
and I take the point about the constants divided by 2,
where there is no loss of accuracy (but not divide by 3?)
but we need to also consider what
users will find useful
and also try to avoid confusion if expectations are not met.

I think people will expect to find names for pi/2 and 2*pi,
and the programs will read more nicely if these are present.
Of course a rational naming scheme is essential, as we have agreed.

I think the balance is tipped in favour of a reasonable number
of "Easily derivable, with little precision lost: 0, 1, 1/2, 1/3, ln(2)/2"
*provided* the cost is small.

Does anyone know what the costs are?
Does it matter if we add a hundred names?
Does it cause code bloat?
Does it case linker constipation?
Does it matter if in double, long double, or function or template, or
template?

Paul

> -----Original Message-----
> From: Ed Brey [mailto:brey_at_[hidden]]
> Sent: Thursday, May 17, 2001 8:08 PM
> To: boost_at_[hidden]
> 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.
>
>
>
> To unsubscribe, send email to: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>