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).
7 I have not concerned myself with efficiency or speed and assumed
Q: is the precision of the algorithms actually so good that it makes a difference if one uses float, double or long double? 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.
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
How many warnings? what type of warning? 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