|
Boost : |
From: John Maddock (jm_at_[hidden])
Date: 2002-12-13 06:34:24
> 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.
Yes we really should get this one sorted out.
> 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?
How about if you pick *one* constant: lets say pi for example, and provide
the differing implementations, plus a summary of the pros and cons of each,
then lets through it open to see if:
a) anyone can do better.
b) which version(s) people prefer.
personally I would prefer not to see multiple versions of the same constants
in use, but other may well disagree.
A good summary of (possibly conflicting) design requirements would be a good
idea as well especially as it's been a while since we discussed this. How
about setting up a page for this on boost's Wiki pages?
To start this off:
1) Must be available for multiple precision's and types.
2) Must be available for use in generic programming.
3) Must be easy to use.
4) Should be suitably scoped in the appropriate namespace.
5) Should do the right thing when used as an argument for template argument
deduction, or overload resolution.
6) Should be easily extended to new types.
7) Should be easily extended to new constants.
Regards,
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk