
Boost : 
From: Daryle Walker (darylew_at_[hidden])
Date: 20020711 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 'builtin' hardware floatingpoint, 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 Cstyle
> 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 Kennistonstyle 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 reopen 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk