RE: [boost] Math constants - (in-)Formal Review?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Maddock Sent: Friday, December 13, 2002 11:34 AM To: Boost mailing list Subject: Re: [boost] Math constants - (in-)Formal Review? Yes we really should get this one sorted out. 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: I have made reasonable try at this in http://groups.yahoo.com/group/boost/files/MathConstants/Math_Constants3.zip personally I would prefer not to see multiple versions of the same constants in use, but other may well disagree. I agree in principle - but in practice there really do seem to be conflicting requirements, which I have tried to explain in my FAQs documentation - see below for link. A good (I hope) summary of (definitely!!! conflicting) design requirements is at http://groups.yahoo.com/group/boost/files/MathConstants/Math_Constants_doc_3.zip (Which I hope is now accessible and formatted better) 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. and to continue 8 Must not cause name pollution/clashes. 9 Must be able to be optimally efficient. 10 Must be a good handle for hardware provided constants. 11 Must provide for pi rather than pi() 12 Must not be too inefficient and troublesome in debug mode. Paul How about setting up a page for this on boost's Wiki pages? If this is the best place/way to discuss - fine. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Math constants - (in-)Formal Review?
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
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Math constants - (in-)Formal Review?
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.
Why won't this work:
struct Pi_impl
{
operator float() const
{ return 3.14...; }
operator double() const
{ return 3.14.; };
operator long double() const
{ return 3.14..;}
};
namespace boost
{
const Pi_impl pi;
}
?
Thorsten Ottosen, AAU
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Math constants - (in-)Formal Review?
Why won't this work:
struct Pi_impl
{
operator float() const
{ return 3.14...; }
operator double() const
{ return 3.14.; };
operator long double() const
{ return 3.14..;}
};
namespace boost
{
const Pi_impl pi;
}
?
Template function overload resolution is one:
std::abs(pi); // oops error
another is that it is not extensible: how for example should I add constants
for boost::interval? Or some other as yet unthought of (or user defined)
type?
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Math constants - (in-)Formal Review?
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
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
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
