Somewhere in the E.U., le 05/11/2004 Bonjour In article <E1CPhm8-0004eI-89@he203war.uk.vianw.net>, "Paul A Bristow" <pbristow@hetp.u-net.com> 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 +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
Thanks for taking on this essential task! Hubert Holin