[boost] Math constants - (in-)Formal Review?

From: Paul A. Bristow (boost_at_[hidden])
Date: 2002-12-13 02:47:27

Some time ago I started what became a long discussion about the presentation
of math constants, like pi.

Eventually these discussions proved inconclusive and there seemed no
acceptable solution, although there was agreement that
collection(s) of highly accurate constants were needed.

After more than a year of effort involving dozens of suggestions from
Boost developers and others, there appear to be disadvantages to all
proposed interfaces, however ingenious.

In the face of all these conflicting arguments,my instinct was (and remains)
to provide ALL the representations of constants,
and see which prove popular.

I therefore propose:

Three groups of constants:
  math_constants will contain a few essential constants like pi, e.
  math_constants_2 will contain less common constants including those
  which cannot be calculated accurately by compilers, like 1/3.
  math_constants_3 will contain more obscure or convenient constants.

1 Three files of constants as MACROs to
    #define BOOST_PI 3.141592653589793238462643383279502884197L
    and three files to #undef
2 Three files of float constants float pi = 3.14F.
3 Three files of double constants. double pi = 3.14
4 Three files of long double constants long double pi =  L.
5 Three files of functions long double pi(){ return 3.14159...}
6 Three files of Kenniston style constants which allow pi or pi()
7 Three files of intervals containing constants interval (pi_lower & pi_upper)

However I am unwilling to put in the substantial effort to
automatically generate these using NTL high precision code
unless Boosters can agree in principle on the file contents.

So before doing more, I would like to suggest a (in-?)Formal Review on the
proposed representation of constants, and agreement on which constants.

Should I submit for a Formal Review?

Paul

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

http://groups.yahoo.com/group/boost/files/MathConstants/Math_Constants_doc_3.zip
http://groups.yahoo.com/group/boost/files/MathConstants/Math_Constants3.zip
A mini-review for new readers:
(for details see very much updated html documentation and the additional files
showing use of the many constants representations).

(I hope that the revised document is readable on all readers.  It was produced
using FrontPage and I hope to have exorcised the MS Word garbage that so
offended Mozilla)

Briefly I propose many different representations for constants, because after
much discussion and experimentation, no universally acceptable format and
disadvantage free format has been found.

1 We agree on the need for accurate math constants
- pi, e, sqrt(2) and i for a start.

2 (Physical constants are a separate matter for their accuracy is not
constant).

3 Some constants cannot be calculated accurately by current compilers
because they use 'built-in' hardware floating-point, and this is unlikely to
change.
Only constants calculated with a higher precision software system, like NTL,
will ensure that the constant is stored as accurately as the floating point
hardware will allow.

4 40 decimal digits are sufficient for all practical purposes,
and compilers are (or really should be) capable of reading decimal digits
into their various internal formats (float, double, long double).

5 A C++ naming scheme for math constants has been devised which is at least
acceptable (if a compromise).

6 Control of precision is essential, but there is opposition to a C-style
solution
using three names for each constant, for example float pi_F, double pi_D,
long double pi_L.
Nor, in Boost discussions, did use of namespaces to separate different
precisions seem acceptable.

7  There are dozens of constants that some users rate 'essential'.
Splitting into several #include files still risks violating the "don't pay
for what you don't use" principle.

8 Only MACROS provide a simple way of avoiding some cost for constants you
don't use.
(but Boosters expressed very strong opposition to MACROs because they pollute
the global namespace, even if #undefs are provided).

9 Users extremely strongly prefer to write "float area = pi * r * r;"

10 There is evidence that some compilers can generate better code from
functions like
"double pi() { return 3.1459;}"
but that this implies writing pi() instead of plain "long double pi".

So the ()s remain the main issue.

Michael Kenniston had a previous interesting suggestion
but which did not seem entirely satisfactory.
He has now produced another which is attached.
Briefly, this allows 'novice' users to write "pi" but
get the effect of "pi()" without too many precision surprises,
yet still allows the 'expert' to write "pi()" and control precision
explicitly.  But there remain some disadvantages - see FAQ.

11 Finally the acceptance of the Interval Library into Boost means there is a
need for intervals containing constants - upper and lower limits.  Examples have
been calculated as 'exact representations' and discussed before. This increases
the number of constants potentially required to achieve the required accuracy.

Paul