Re: [boost] Math constants - Some suggested constants

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-11-06 17:00:45

From: "Paul A. Bristow" <boost_at_[hidden]>

> Here are some suggested constants, in three groups:
> 
> 1  Basic math constants.  The absolute minimum?
> 2  More, and some derived math constants.
> 3  More obscure (but essential for some people) math constants.

The idea of breaking down the constants into groups is a good one.  To make the groups more definate, could we come up with some logical rules to define what goes in each.  Drawing from existing texts is a good starting point, but a sorting algorithm would be even better.

Here's a suggestion:

Group 1: Common constants that cannot be specified by a finite sequence of +-*/^ operations of other constants.  This includes pi, e (which I assume was an accidental ommission from your group 1 list), phi, and euler.

Group 2: Common run-time derived constants.  This would contain much of what is in your groups 1 and 2.

Group 3: Common compile-time derived constants with high loss of precision.  Some experimentation may be needed to see how many there are.  Depending on the results, it may make sense to also add related constants without much precision loss for interface consistency.

Group 4: Uncommon constants - basically your group 3.

Some observations on this:

1. Many constants are the return values of functions taking a certain parameter.  In a perfect world, these wouldn't be constants at all, but would simply be written sqrt(2) or gamma(1/3.), or the like.  The key aspect is that there would be no special cases: sqrt(5) would be not look different than sqrt_2.  Unfortunately, I don't think that there is any practical way to implement this without intrinsic compiler support, so such constants are a necessary evil when speed or precision is crucial.  In that respect, it makes sense for them to go into a "necessary evil" group, which differentiates them from constants such as pi that are most natural as constants, rather than functions.

2. To keep at least some uniformity, for each constant that is a function return value, the actual function should be available.  Sqrt and cos are done for us.  But gamma constants should not be added without a gamma function.

3. Given the above observations, only group 1 (as I've suggested) constants should be considered for standardization.  The trend should be to move the language away from performance hints to compilers (e.g. inline), rather than toward it.  Intrinsicly performing high-quality compile-time sqare root should become a QoI issue for compilers that users can count on, just like what is possible today for operator*(double,double).  Enshrining special cases for these functions in the standard will only tend to snuff any such effort.

4. Following this reasoning provides an opporunity to keep the documentation very simple for common users.  Only group 1 constants and general math functions need to be exposed to the main stream, with a note that if profiling indicates that speed or precision is paramount for a given block of code, there are some precomputed derived values, which are documented separately in an "advanced" section.

5. Given the above reasoning, note that it makes sense to shift the nature of the library a bit from math constants to math constants and functions.  I envision the documentation providing a complete list of all supported fundamental math constants and functions, with references to functions in std, where appropriate.

Question:

The argument that a constant like "two" is handy is not new.  However, I still don't understand where the handiness comes in.  Could you provide an example?