>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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
