RE: [boost] Advanced match constants scheme

From: Paul A Bristow (boost_at_[hidden])
Date: 2003-06-20 08:58:13

|  -----Original Message-----
|  From: boost-bounces_at_[hidden]
|  [mailto:boost-bounces_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 non-expert 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 template-function scheme.

These exactly representable values can only be calculated with a 400-bit
floating point system - I have used NTL, but there are a few others.
This doesn work at the speed of light, so I believe pre-calculating 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 constants--an 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.