Boost logo

Boost :

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

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'
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:
|| oost

Boost list run by bdawes at, gregod at, cpdaniel at, john at