Re: [boost] More Math Functions for Statistics (and TR2)

From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2005-12-03 13:31:42

Hi Paul,

Thanks for doing this important work.

 > Some of the 'issues' are:
 >
 > 1  Floating-point format. I have assumed IEEE formats, but try to 
check and
 > warn if not. All
 > built-in types can vary in precision, especially double and long 
double: I
 > have shown an
 > example of selecting long double having 53, 80 or 128 significand 
bits (all
 > IEEE formats).

Q: is the precision of the algorithms actually so good that it makes a 
difference if one uses float, double or long double?

 > 7  I have not concerned myself with efficiency or speed and assumed 
that the
 > compiler will
 > inline and otherwise optimise away inefficiencies from wrapping.

Good.

 > 9  Cephes deals with errors (for example, from wrong parameter values) by
 > the then
 > conventional method of calling matherr & setting a global math error 
no, and
 > printing a message,
 > rather than throwing exceptions.
 > But I note that the system-wide error numbers (XENIX) in the Microsoft
 > error.h include files
 > are undocumented, and conflict with the Cephes codes. And C99 (and thus
 > TR1?) no longer
 > REQUIRE a math error to set errno. The simplest solution would be to 
change
 > the existing
 > matherr function to set errno and NOT print any message:  users would 
always
 > be free to change
 > this module to suit their other requirements. I would NOT wish to 
implement
 > the C99 exception
 > handling, nor C++ floating_point exceptions.
 >
 > __Detailed__ recommendations about if and how this error handling 
should be
 > made more 'standard',
 > perhaps using error.h would be welcomed.

I guess throwing is out of the question because of C compatibility?
How are error handled in the new tr1 math functions?

 > 12 The Cephes code produces a lot of warnings when compiled in 'strict'
 > mode.  I have ignored
 > these, although they suggest that the C code does not meet todays 'picky'
 > standards.  However
 > a full revision would be a big undertaking with risks of introducing 
errors:
 > my impression is
 > that most of the warnings look spurious.

How many warnings? what type of warning?

 > 14 Finally may I reiterate that the objective of this implementation 
is to
 > persuade the C and
 > C++ Standards groups to standardize the signatures of these 
functions:  it
 > will be possible
 > for better implementations to be produced in the future by both open 
source
 > and commercial
 > organisations like Dinkumware.

Right. And it will probably make a big difference to some vendors
that the functions are now in Boost.

When you write a revised paper, please enhance the "motivation" section
by drawing from exampes in other languages. If it has been part of 
Visual Basic, then write it. If similar functions are used oftenin Java, 
then tell something about it.

Consider how to answer these questions:

1. why so many functions? are they all really needed?

2. would it make more sense to standardize a usability layer on top of
    these functions?

br

Thorsten