Math constants: Inclusion requirements

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-10-30 08:54:18

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?