Paul A Bristow wrote:
In previous discussions, the main issues debated were:

1 Control of precision is essential,
and some users wanted to be able to use
float, double and long double at the same time.

"at the same time" is exactly what the "separate headers approach" doesn't provide if you can only include one at a time IIUC.


2 Avoiding paying for what you don't use, which leads to

Hm, there is some small overhead, but not much IMHO. In fact far less than a lot of other boost libraries. :)


2a MACROS provide a simple way of avoiding some cost for constants you don't use, (Although some Boosters were opposed to MACROs because they pollute the global namespace).

I'd like to backup the latter. With MACROs, you cannot add a 'using namespace boost::math;' and use a plain 'pi' instead of 'BOOST_PI'. Using MACROs is a pain and should be avoided if possible. And it's IMHO possible in this case.


3 Efficiency

Some compilers can generate better code from functions like "double pi() { return 3.1459;}"
but that this implies writing "pi()" instead of plain "pi".

Yes!


4 Appearance

BUT Users extremely strongly prefer to write "float area = pi * r * r;"

So the ()s remain a MAJOR issue.

But this is exactly what my code tries to do. You write 'pi', and when using it, all calcalations are forwarded to use the value returned from a function (actually pi_value<T>::operator()). Some magic is provided for convenience like in the example above and you can select the type explicitly be using a static_cast. AFAICS you get all what you are asking for...


I see nothing wrong with your suggestions and examples,
but I don't yet understand
how your proposal helps to meet this last 'requirement'.

I don't see the problem as I think I do meet the requirement. Have I missed something? Or is this an issue of a specific compiler's optimization strategies? I don't think that it's to hard for a compiler to generate good code from the code I showed, but I haven't actually measured it (and I can't for all compilers). Do you think that the code is inefficient or do you actually have evidence?


Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [EMAIL PROTECTED], web: http://www.aixigo.de


_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to