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: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 07 June 2003 00:20 | To: [EMAIL PROTECTED] | 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 | | _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost