Boost logo

Boost :

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
I propose to float (sorry!) lists when/if some consensus on naming is


Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
+44 1539 561830
Mobile +44 7714 33 02 04

> -----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: Unsubscribe:

Your use of Yahoo! Groups is subject to

Boost list run by bdawes at, gregod at, cpdaniel at, john at