[boost] Re: Math functions - requirements 'spec'

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2004-11-05 10:30:10

Somewhere in the E.U., le 05/11/2004

   Bonjour

In article <E1CPhm8-0004eI-89_at_[hidden]>,
 "Paul A Bristow" <pbristow_at_[hidden]> wrote:

> Following the view of C and C++ Working groups at Redmond
> that a working implementation of my proposal for math functions
> was a necessary condition for consideration for a TR-2 standard,
> 
> I have been skirmishing with the problems of converting
> Stephen Moshier's Cephes code into something that works for both C++ and C.
> 
> Several issues have emerged, mainly revealing my ignorance with C
> - a state of bliss in which I would have preferred to remain ;-)
> 
> 1  Should I no longer cater for non-compliant compilers (usually old-style
> function specifications?
> 
> I only have MSVC 8.0 available.

      Yes, please stick to compliant compilers (or at least, do not feel 
you have to bend backwards too much for the non-conforming ones).

> 2  How do I check that my code is Standard C compatible (as well as C++)?

[SNIP]

> 5  Do I have to use exclusively C /* */ style comments :-((?  (Or can I
> assume that C compilers will understand // comments?)

      I must say I *strongly* disagree with having code with is C 
compatible, mainly because this will greatly hamper genericity (or at 
least convenient and safe parametrisation of code).

      Even if the code turns up only feasible for, say, float and 
double, I strongly believe it should be templated upon the floating 
type, with specializations if need be. The C library in C++ clothing 
approach is just plain wrong, IMHO.

> I have also immediately come up against the problems of IEEE 754 compliance,
> argument checks, NaN, infs and exception throwing.

> 6  Should I assume IEEE 754 compliance and signal #error "Only works with
> IEEE compliant compilers"?  How do I check with C - numeric_limits ::
> is_IEC559 equivalent?  Or would it be foolish to rule out the some older DEC
> machines?
> 
> 7  Do you recommend making NaN and inf checks optional?
> 
> 8  How do I find if they are available, automatically but portably?
> 
> 9  Can I assume isnan(float, double and long double) with C and with C++?
> 
> 10 How do I detect isinf?  Do I use FPclass for detecting isinf? (pos and
> neg?)

      I started a thread on comp.std.c++ a while back about NaN and Inf 
(http://groups.google.com/groups?hl=en&lr=&threadm=b172eb2f.0106180508.49
0a6401%40posting.google.com&rnum=5&prev=/groups%3Fhl%3Den%26lr%3D%26q%3DH
olin%26btnG%3DSearch%26meta%3Dgroup%253Dcomp.std.c%25252B%25252B). 
Basically, we are out of luck using only the provisions of C++. If we 
assume that in addition we abide by the relevant IEEE/IEC standards, we 
can roll our own isinf and isnan (with good suggestions in the thread). 
I still believe we should have language support for this!

> 11 Do you recommend making throwing exceptions optional with C++?

      Computations *should* throw if necessary. This *should not* be an 
option. However, Inf and NaN should be reported as such, and not throw. 
Using "#error" should be deprecated (it's main use should be for the 
maintenance of legacy code, not for the development of new one).

> 12  Should I scrap all the hexadecimal (mainly polynomial) constants on the
> grounds that conforming compilers should read decimal digit strings
> 'correctly' - getting the nearest representable value.  Is this true for
> both C and C++?

      Keep them, they are hardly a nuisance... You can put decimal 
equivalents in comments, though...

> 13  Do you also recommend making checking arguments optional (with #ifdefs)?
> So that those who want the ultimate in speed at any risk can switch checking
> off?

      First make it do the right thing, then only perhaps worry about 
making it fast... (this comment of course does not preclude using 
asymptotic methods for which the error term can be estimated). In other 
words, use algorithms that are fast, but do not remove the safety nets!

> Comments welcome.
> 
> Paul
> 
> PS
> 
> Slightly updated versions of my TR2 proposal are at
> 
> http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.doc
> 
> http://www.hetp.u-net.com/public/math_stats_functions_tr2_v2.pdf

      I'll try to take a look next monday.

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

   Thanks for taking on this essential task!

         Hubert Holin