RE: [boost] Math constants: Inclusion requirements

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-10-30 12:38:03

In general I agree with this, however the whole point is to ensure
that NO compilers don't make any difference to the calculated value,
so NO compiler is suitable as a benchmark - these values ARE the benchmark!

Although 2 * pi is almost certainly going to be exactly
calculated, it (and a few others) are popular enough to be
worth inlcuding.

We have been through considerable discussion about portability,
and I feel I have justified providing a reasonable number,
split into a few header files.

Of course some math constants will be essential to some and obscure to
others.
I propose to float (sorry!) lists when/if some consensus on naming is
reached.

Paul

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

> -----Original Message-----
> From: Ed Brey [mailto:edbrey_at_[hidden]]
> Sent: Tuesday, October 30, 2001 1:54 PM
> To: boost_at_[hidden]
> Subject: [boost] Math constants: Inclusion requirements
>
>
> I'd like to take a stab at formalizing rules that would govern
> which constants do and do not get included into the math
> constants library.  It is clear that something more than
> "commonly used" is called for here, since that criterion varies
> significantly from domain to domain and person to person.  An
> arbitrary set of requirements will provide less enhancement
> dollar per learning-curve millivolt than one that fits a good set
> of requirements.
>
> A general goal is to separate truly global constants from "pet"
> constants, that is constants that a few find really handy, but
> don't add much value because they are very obscure or are
> redundant with existing capabilities.  Pet constants are better
> kept in a private constant stash close to the pet owner.
>
> So here's the criteria that I'd like to consider:
>
> A constant should be included if and only if:
> (1) It is generally useful in the field of mathematics, and
> (2) It cannot be derived mathematically from an expression
> involving only +,-,*,/ on a finite number of exact literals and
> other math library constants, or
> (3) Derivation as in (2) leads to inaccuracy greater than epsilon.
>
> My thinking with regard to point (3) is that accuracy beyond
> epsilon would very rarely be needed.  However, if there are some
> good case studies that would indicate otherwise, I'd be
> interested in hearing about them.
>
> In making the decisions for (3), it would probably be reasonable
> to benchmark primarily using g++, since it is free and portable,
> and hence excellent for benchmarking, with some sanity checks on
> other compilers.
>
> Comments?
>
>
>
> Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/