
Boost : 
From: Paul A Bristow (boost_at_[hidden])
Date: 20030620 08:58:13
 Original Message
 From: boostbounces_at_[hidden]
 [mailto:boostbounces_at_[hidden]] On Behalf Of Augustus Saunders
 Sent: 20 June 2003 01:32
 To: boost_at_[hidden]
 Subject: [boost] Advanced match constants scheme
 >PS I'd like to hear more views on this 
 I do find the prospect of writing natural, effecient,
 and precise code for solving various equations a worthwhile goal.
 So, since you asked for comments, here's my nonexpert thoughts.
Your participation is most welcome 
I had started to fear that nobody was interested.
 Nobody, however, is thrilled with polluting the global namespace,
 so unless Paul Mensonides convinces the world that macro
 namespaces are a good thing, some of us need convincing that
 macros are really the way to go.
I only suggested that they should be an option, and not preferred.
(The marginal cost of generating macro values is almost zero).
 In the course of discussion, a more ambitions plan was proposed.
 Instead of just providing a big list of constants, IIUC it
 was suggested that an expression template library be used to
 allow common constant combinations like 2*pi or pi/2 to be
 expressed with normal operators. This seems good, it
 provides a natural syntax and reduces namespace clutter and
 is easier to remember. However, since the idea was to use a
 special math program to generate high precision constants,
 I'm not sure whether an ETL can eliminate the need to
 compute things like 2*pi with the third party program. So
 I'd like to know does:
 1) 2*pi ==> BOOST_2_PI
Well, in this case yes for all binary floating point machines, because
you just add one to the exponent (assuming it doesn't overflow).
For the upper and lower values of the interval containing pi, the I
believe that answer is a definite no because the interval value must be
'exactly representable' and thus depends on the floating point layout
(number of significand bits). So there isn't a single pair of macro
upper and lower values.
For this the interval library authors preferred the template approach.
template_intervals_constants.hpp (and test..) provides an example of how
this could be implemented with the Kenniston templatefunction scheme.
These exactly representable values can only be calculated with a 400bit
floating point system  I have used NTL, but there are a few others.
This doesn work at the speed of light, so I believe precalculating is
essential.
But a better question would be about pi and 3 (or 5 or 10...) when I
believe that the answer to 3*pi ==> BOOST_3_PI ? is a definite maybe.
And of course if exp and log, sin, cos etc the answer is almost
certainly not.
There are quite a lot of these.
 where BOOST_2_PI is a constant already defined, or does
 2) 2*pi ==> BOOST_PP_MULT( 2, BOOST_PI )
 using high precision preprocessor math (or something) to
 sidestep the need for defining BOOST_2_PI in the first place?
This would be fine  but a high precision preprocessor doesn't exist
yet, to my knowledge and would be seriously slow.
 If this was implemented the first way, then I would see any
 "advanced" scheme as being a layer on top of the actual
 constant library, to give it a more convenient interface.
 The second way might actually impact what constants get
 defined in the first place, in which case we should talk it
 out enough to know what constants should be defined. But
 I'm not sure the possibility of an advanced scheme should
 prevent us from defining the basic constantsan expression
 framework could be another library, right?

 Augustus
Right. And Daniel's scheme already looks to permit this
(but not for intervals  or complex? another 'requirement').
So for these two reasons, I am resigned to a larger set of constants
than might seem necessary at first sight. If you look at the constants
actually used, there really are not that many (few dozen?). We
previously discussed a reasonable rational naming scheme which would
allow one to guess but resort to calculation if not found in the library
list.
Paul
PS I'd still be grateful for more views on this issue.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk