[boost] Re: Math Constants Formal Review - ()s are a key issue.

From: Daniel Frey (daniel.frey_at_[hidden])
Date: 2003-06-17 05:19:02

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: [phone], fax: [phone]
eMail: daniel.frey_at_[hidden], web: http://www.aixigo.de