Re: [boost] Ann: Floating Point Utilities Review starts today

From: John Phillips (phillips_at_[hidden])
Date: 2008-02-26 16:02:37

Johan Råde wrote:

> John Phillips wrote:
> 
> 
>>I am also concerned about merging it into the MathTools library. That is 
>>certainly where it belongs in a logical sense, 
> 
> 
> I'm not so sure about that.
> Mathematics deals with real numbers.
> Computer science deals with floating point numbers.
> Ask a typical mathematician what a NaN, denormal number or negative zero is,
> and you are most likely to get a blank stare.
> 
>  From a purely logical point of view it makes sense to have a separate floating point library,
> just as there is a separate integer library.
> 
> A more pragmatic reason to keep the floating point functions together with the proper math functions
> (exponential functions, trig functions, special functions, statistical distributions etc.)
> is that in TR1 both are declared in the header <cmath>.
> 
> --Johan
> 

   Sorry for miss-naming and calling the Math Toolkit by the incorrect 
MathTools, but the basis for my concern that they will be merged is from 
the review announcement, where John Maddock says:

John Maddock wrote:

 >1) Floating point classification routines: these are optimised
 >implementations of the C99 and C++ TR1 functions fpclassify, isinf, 
 >isnan,
 >isnormal and isfinite.  From Boost-1.35 onwards these are already a 
 >part of
 >Boost.Math (see
 >http://svn.boost.org/svn/boost/trunk/libs/math/doc/sf_and_dist/html/math_toolkit/special/fpclass.html) 

 >so if accepted the two implementations will get merged.
 >
 >The review here should focus on the implementation used, and testing on
 >whatever platforms you have available - in particular are there any
 >circumstances (compiler optimisation settings etc) where this 
 >implementation
 >breaks?

 >2) Sign manipulation functions: implementations of the C99 and C++ TR1
 >functions copysign and signbit, plus the changesign function.  Two of 
 >these
 >(signbit and copysign) are currently undocumented members of 
 >Boost.Math, and
 >again the two implementations will get merged if this library is 
 >accepted.

 >Again the main focus of the review here is the implementation, and 
 >testing
 >thereof especially in the presence of compiler optimisations.

As for typical mathematicians and NANs, denorms and such, I would tend 
to disagree with you. My numerical analysis books certainly include 
these ideas (Starting with a book by Hamming in 1973, at least.), and 
even math programs that don't require that class strongly encourage it 
(The one I teach in requires it, and these concept are taught in it.).

However, all of that misses my concern. I think the library you are 
providing is important and useful for anyone who wants to do 
computational numerics well, and I want to make sure that it is not lost 
for the casual reader of the boost documentation. If it gets merged into 
the Math Toolkit documentation as the notes above imply to me (and I'm 
sorry if I'm miss interpreting them), then I'm afraid that many users of 
boost tools will miss both the significance and utility of your work.

I would just like to make sure that if such a merger happens, care is 
taken to highlight the utilities properly.

John