From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2005-12-03 13:31:42
Thanks for doing this important work.
> Some of the 'issues' are:
> 1 Floating-point format. I have assumed IEEE formats, but try to
> warn if not. All
> built-in types can vary in precision, especially double and long
> have shown an
> example of selecting long double having 53, 80 or 128 significand
> 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
> compiler will
> inline and otherwise optimise away inefficiencies from wrapping.
> 9 Cephes deals with errors (for example, from wrong parameter values) by
> the then
> conventional method of calling matherr & setting a global math error
> 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
> the existing
> matherr function to set errno and NOT print any message: users would
> be free to change
> this module to suit their other requirements. I would NOT wish to
> the C99 exception
> handling, nor C++ floating_point exceptions.
> __Detailed__ recommendations about if and how this error handling
> 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
> 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
> persuade the C and
> C++ Standards groups to standardize the signatures of these
> will be possible
> for better implementations to be produced in the future by both open
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk