RE: [boost] Re: Math Constants Formal Review - accuracy is vital too

From: Paul A Bristow (boost_at_[hidden])
Date: 2003-06-18 09:15:24

|  -----Original Message-----
|  From: boost-bounces_at_[hidden] 
|  [mailto:boost-bounces_at_[hidden]] On Behalf Of Daniel Frey
|  Sent: 17 June 2003 11:19
|  To: boost_at_[hidden]
|  Subject: [boost] Re: Math Constants Formal Review 

I have now studied your code - only on paper - rather more carefully,
which I apologise for not doing carefully enough before.
It seems to have some similarities to the code written by
Michael Kenniston which is now being reviewed.
I am not sure that I fully understand how and why it works,
and I do not yet see what advantages it may have.
I would much welcome more independent expert input,
but I do note:

The float and long double constant values do not include F and L.
Previous agreement was that this was needed to to avoid any chance of
computation by the compiler. This could of course be easily added.

A vital feature is that the compiler should only use the
40 decimal digit literal values provided and should NOT do any
calculation.
This is because the compiler will only use the floating-point accuracy
of the
hardware whereas the important feature of the values provided is that
they are
calculated by a much higher precision software system, in this case NTL.
It is difficult to foresee compiler writers opting to use higher
accuracy
floating-point because it would be much slower, and only rarely add any
value.

Maximum possible accuracy is a central feature,
promising the best possible portability,
especially for intervals where every really bit really counts.

It was also agree that any casting to obtain other types did not
garanteed accuracy and this was why the proposed code uses namespaces
to allow selection of the FP size either individually:

boost::math::double_constants::pi

or 

boost::math::float_constants::pi

or 'globally' - suiting most applications

using namespace boost::math::double_constants;

and then accessing using just plain pi.

I feel that static_casting definitely needs to be avoided.
Perhaps your code can achieve this by some modification?

Although your operators are neat, speeding -sin(pi/two),
my suspicion is that it is better to pre-calculate as many
constants as possible, and as accurately as possible.  
I don't think this counts as "premature optimisation" :-)

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB  UK
[phone]
pbristow_at_[hidden]