[boost] Advanced match constants scheme

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2003-06-19 19:31:31

>PS I'd like to hear more views on this -
>previous review comments were quite different,
>being very cautious about an 'advanced' scheme like this.

Disclaimer: I am neither a mathemetician nor a scientist (I don't
even play one one TV).  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.

As I understand it, the original proposal's goal was to provide
conveniently accessible mathematical constants with precision greater
than current hardware floating point units without any unwanted
overhead and no conversion surprises.  Additionally, it needed to
work with the interval library easily.  To work around some
compilers' failure to remove unused constants or poor optimization,
we wound up discussing function call and macro interfaces.  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.

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

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?

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

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com