Math Constants

Introduction

accuracy

Naming convention

Which constants

Introduction

Mathematical constants (like Archimedes' pi) are exceedingly unlikely to change, whereas estimates of physical ‘constants‘ (like Planck's h) are certain to vary. Physical constants usually have a known uncertainty, usually greater than even the accuracy of float representations, whereas mathematical constants can be calculated to an arbitrarily high precision. So it would be confusing to store mathematical and physical constants in the same header file.

Accuracy

Naming convention

Discussion about naming convention made very clear that it is not possible to please everyone!  Worse still, there seems to be an irreconcilable conflict between name-first and factor-first conventions when names of upper and lower limits of intervals are required. Allowing aliases has some disadvantages. 

Some urgent desires to use an alternative name can be met using macros to 'rename', or using the C-style macros #define values, for example:

const double My_Very_Own_Name_for_pi  = BOOST_PI;

Naming demands compromises - for this version I have chosen the upper and lower without underscores_ h, for example, oneDivTwoPi.

In general, a C++ Standard Library style is used, favouring longer and easier to read names over ease of typing, and all lower case and underscore _ as separator. Of course, names cannot start with a digit, so words, like two and half, are used instead. C99 names are used where appropriate, but names are not in all capitals as used for constants in many C programs. The rationale is that these names are variable names and not macro or #define names for which ALL CAPITALS are conventionally retained in C++ programs. Some examples, and the rationale for them, should make this clearer than an attempt to write a formal specification.

A major difficulty is the desire to put the name first and follow by type. For example:

pi_div_2  versus  half_pi

And yet there was very strong preference for two_pi rather than pi_twice or pi_times_2.

pi  // Prefer lower case only - use uppercase only for class names.
loge_pi // much clearer than logepi
sqrt_2 // shorter than sqrt_two
log_2 // clearer with separating _ than log2, despite more typing.
but Boost favours clarity over curtness.
// and reserve log2 for log to base 2, log10 for log to base 10.
// sqrt is commonly used and shorter than square_root_2.
cbrt_2 // ugly, but is C99 name.
ten // can’t be 10 so use the word ten instead.
third // shorter than one_div_three.
one_div_sqrt_2 // one_div rather than reciprocal – short but clear.
// _div clearer than _on or _upon or _over.
half_pi // rather than pi_div_2.
pi_sqr // pi_squared is rather long.
two_pow_three_halves // two_pow_three_div_two is ambiguous.
minus_loge_loge_2 // can't start with - so use word.

There are always problems with more complex constants where brackets would be used

two_pow_three_halves // two_pow_three_div_two is ambiguous.

Explicit typed names can only sensibly follow the C99 convention:

pi_f // float
pi_d // double
pi_l // long double
pi_i // integer???
 pi // nearest to pi (usually either upper and/or lower interval limit)
pi_l // pi interval lower limit
pi_u // pi interval upper limit

and where both floating-point type AND upper or lower limit are fixed:

pi_f_l // pi float lower limit
pi_l_l // pi long double lower limit
pi_l_u // pi long double upper limit

Which constants?

1. Basic math constants. The absolute minimum?
2. More, and some derived math constants, noting that some can be calculated by compilers without loss,  for example * or / factors of 2).
3. More obscure (but essential for some people) math constants.

I have indicated some rationale for including each one,
drawing on the 'authority' of 3 texts, and Boost discussions:

1 Donald E Knuth, Art of Computer Programming,
2 John Hart, Computer Approximations, and
3 Stephen Moshier, Math Functions, Cephes math function library.
4 Morris, ACM 715 & Brown CDFlib collection of math functions used in statistics.

as a guide to what has been used in typical math work, in particular those constants that would be required for a math function library..

All the builtin sqrt, log, trig and pow functions are especially liable to be inaccurate, (and seriously inaccurate at times) and all lead to run-time code which is extremely unlikely to be optimised. I indicate this by saying, for example, 'avoid log()'.

1 Basic math_constants.hpp
 

2 Additional

Again note that some of these may be calculated accurately by some compilers, but are good for clear programs, and avoid any run-time code for debug and/or less-optimised code.
 

A handful of real constants:

3 (More) Obscure

http://www.hetp.u-net.com/public/mathconstants/rational.html, Revised 5 May 2005

© Copyright Paul A Bristow 2002-2005. All Rights Reserved.