[boost] Math Constants Formal Review

From: Jaap Suter (J.Suter_at_[hidden])
Date: 2003-06-06 08:45:45

To all,

Today is the start of the formal review of the Math Constants library by
Paul Bristow. The review will run until Sunday June 15th.  I will be serving
as review manager.

The Math Constants library is a collection of very accurate mathematical
constants for C ++ (and C) programs. These are like to be useful even by
programs just computing circumferences of circles!

A special feature of this collection is that the constants values are a
little more accurate (40 decimal digits) than can be represented by current,
and currently foreseeable, floating-point hardware. The mathematical
constants collection is convenient in that it does not require a search of
reference sources and is useful because it ensures that the values are as
accurate as possible and as portable as possible between different systems.
The constants have all been calculated using high-precision software working
with up to 400-bit precision giving about 130 decimal digits. (The precision
can be chosen and is limited only by compute time). The accuracy selected
(40 decimal digits) exceeds the accuracy of reasonably foreseeable
floating-point hardware.

The objective is to achieve the full accuracy possible for all real-life
computations. This has no extra cost to the user, but reduces irritating,
and often confusing and hard-to-trace effects, caused by the intrinsically
limited precision of floating-point calculations. The slightest symptom is a
spurious least-significant digit; at worst slightly inaccurate constants
sometimes cause algorithms to fail because internal comparisons just fail.

Following this anouncement is a brief resume and FAQ on the long discussion
that preceded this formal review.

You can find the latest documentation, including a bigger FAQ section, at:

http://groups.yahoo.com/group/boost/files/MathConstants/Math_Constants_doc_3
.zip

Some examples are available at:

http://groups.yahoo.com/group/boost/files/MathConstants/Math_Constants3.zip

Please state in your review comments how you reviewed the library and
whether you think the library should be accepted into Boost. Further
guidelines for writing reviews can be found on the website at:

http://www.boost.org/more/formal_review_process.htm#Comments

 Thanks,

 Jaap Suter

> A Mini-recapitulation of the long saga so far, for new readers, by Paul
> Bristow:
>
> (for details see very much updated html documentation and the
> additional files showing use of the many constants representations).
>
> Briefly I propose many different representations for constants,
> because after much discussion and experimentation,
> no universally-acceptable format and no disadvantage-free format has
> been found.
>
> 1 We agree on the need for accurate mathematical constants
> - pi, e, sqrt(2) for a start, but many others are 'essential' to some
> people.
>
> 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
> (except intervals see below),
> 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 inevitably 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 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 a major 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 it 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 real 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 (for example, 2_pi interval IS
> needed).