RE: [boost] RE: Math Constants Formal Review - recap & summary

From: Paul A Bristow (boost_at_[hidden])
Date: 2003-06-08 09:56:53

A Mini-recapitulation of the _long_ saga so far:

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).

|  -----Original Message-----
|  From: boost-bounces_at_[hidden] 
|  [mailto:boost-bounces_at_[hidden]] On Behalf Of Daniel Frey
|  Sent: 07 June 2003 00:20
|  To: boost_at_[hidden]
|  Subject: [boost] RE: Math Constants Formal Review
|  
|  
|  I currently vote neither yes nor no. I just need to get a 
|  better understanding of what is intended to be included into 
|  boost from the files provided.
|  
|  On Fri, 06 Jun 2003 19:21:08 +0200, Paul A Bristow wrote:
|  
|  > but I hope the review can concentrate on what emerged 
|  previously as 
|  > the _really_ tricky issue of how to _present_ the values in C++,
|  
|  I looked at the files and I think that they need some clean 
|  ups. Also, I don't really see the concept behind it. How are 
|  the values presented and how does your way compare to other 
|  options? (Well, I basically can fiure out the first part, 
|  but without the second, I can't really understand it). Maybe 
|  you can provide some links to the key messages of the 
|  discussion that lead to it or give us a short summary.
|  
|  Another point I am missing is a way to extend the constants 
|  for user-defined types. Something like numeric_limits<> 
|  comes to mind. I think that this is a must-have feature as 
|  people that write applications that need lots of these 
|  constants are likely also using types with higher precision 
|  that the standard types provided by the language. Without a 
|  way to teach the constants-framework the new types, they 
|  will create wrappers and thus they won't use the intended 
|  boost-/standard-way to access the variables.
|  
|  Regards, Daniel
|  
|  _______________________________________________
|  Unsubscribe & other changes: 
|  http://lists.boost.org/mailman/listinfo.cgi/b|  oost
|  
|