[boost] Re: Math Constants revisited

From: Daryle Walker (darylew_at_[hidden])
Date: 2002-07-11 00:46:56

on 7/8/02 7:18 AM, Paul A. Bristow at boost_at_[hidden] wrote:

> 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.
> 
> I have been waiting for some time so see if new ideas would emerge, and if new
> compiler versions would change Boosters views. GCC 3.1 and MSVC 7.0 are now in
> wide use, and Michael Kenniston has provided a new (second) proposal for
> avoiding the main dispute.
> 
> To summarize for new readers: (for details see much updated html documentation
> and the previous constants in the files section)
> 
> http://groups.yahoo.com/group/boost/files/MathConstants/Math_constants.htm
> 
> 1 We agree on the need for accurate math constants
> - pi, e, sqrt(2) and i for a start.

I don't think we need "i" or any other complex constants.  The imaginary
unit is just a complex number with a zero real part and a imaginary part of
one, which the compiler can synthesize easily.  I don't using your technique
on complex numbers can be any better than the user doing

    std::complex<double>  my_constant( 0, 3.14159 );

themselves, since a complex number type must have two components (of its
value type).

> 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 reluctance to MACROs because
> they pollute the global namespace, even if #undefs are provided. (Only edit
> cut 'n' paste "const double pi = 3.14...;  area = 3.14159 * radius * radius"
> avoids any runtime cost - will the embedded coders do this anyway?)
> 
> 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. A few example below, and details in attached
> files. pi.zip contains a simple demo of how it works - with an seriously
> reduced accuracy for pi - before you get excited! real_constants.zip gives
> more examples, including a complex constant, and some tests. The outputs using
> MSVC 7.0 are appended as a comment.
> 
> The downsides of Kenniston's Kunning Scheme 2 are, as I see it:
> 
> 1 It stresses compilers - there is disagreement about what should compile.
> 
> 2 It stresses the C++ language definition.
> Is a explicit struct constructor required even if it is not used?
> The language lawyers disagree.
> This may be a significant issue if many constants are provided.

You're talking about:

    struct pi_tag;

versus:

    struct pi_tag {};

right?  I don't think you need the braces unless the compiler thinks it
needs something about the structure of the type (e.g. its size).  However,
the Standard iterator tag types have the braces.

> 3 It stresses compilers ability to optimise away unused bits, without which
> there is a significant risk of code bloat which might negate any advantage of
> using functions over constants. This could be a major nuisance in debug mode
> when optimisation may be lacking, even if the release code is ideal.
> 
> In the face of all these conflicting arguments, my instinct was (and remains)
> to provide ALL the options and see which proved popular.
> 
> I therefore propose to offer for formal review:
> 
> math_constants will contain a few essential like pi, e.
> math_constants_2 will contain constants 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 BOOST_MATH_CONSTANT_PI
> 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()

Maybe we should stick to the Kenniston-style constants only.

> However I am unwilling to put in the significant effort to
> automatically generate these using NTL high precision
> unless Boosters can agree in principle on the file contents.
> 
> So I would like to re-open the discussion with some sample files:
> 
> http://groups.yahoo.com/group/boost/files/MathConstants/pi.zip
> 
> http://groups.yahoo.com/group/boost/files/MathConstants/real_constants.zip

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com