----Original Message---- From: Johan Råde
template<class T> bool is_nan(T a) { return a != a; }
1. Do these implementations work an all platforms?
I believe is_nan is vunerable to over-eager optimizers for built-in types.
2. The category not-a-number can be divided into the sub-categories quite not-a-number and signalling not-a-number. ^^^^^ Should be "quiet". This error has continued throughout the email chain, so it is obviously not just a simple typo (or it is getting copy-and-pasted).
-- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894
Martin Bonner wrote:
----Original Message---- From: Johan Råde
template<class T> bool is_nan(T a) { return a != a; }
1. Do these implementations work an all platforms?
I believe is_nan is vunerable to over-eager optimizers for built-in types.
If implemented that way, then yes: only compilers in strict IEEE mode and probably with optimisations turned off will do the right thing. It won't work at all on platforms with non-IEEE arithmetic :-( Which I why I routed everything through fpclassify: try get it right once in one place and hopefully it doesn't turn into a maintenence problem :-) Of course if the platform has native floating point classification macros then these should be used: they're likely to be much more efficient than "generic" solutions. Unfortunately I found several platforms with native macros that didn't actually do the right thing in all cases during testing of that code :-( John.
John Maddock wrote:
Martin Bonner wrote:
----Original Message---- From: Johan Råde
template<class T> bool is_nan(T a) { return a != a; }
1. Do these implementations work an all platforms? I believe is_nan is vunerable to over-eager optimizers for built-in types.
If implemented that way, then yes: only compilers in strict IEEE mode and probably with optimisations turned off will do the right thing. It won't work at all on platforms with non-IEEE arithmetic :-(
Which I why I routed everything through fpclassify: try get it right once in one place and hopefully it doesn't turn into a maintenence problem :-)
Of course if the platform has native floating point classification macros then these should be used: they're likely to be much more efficient than "generic" solutions. Unfortunately I found several platforms with native macros that didn't actually do the right thing in all cases during testing of that code :-(
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
John, You seem to have thought through these issues carefully. When will you submit the floating point properties library to Boost? I need it. Based on your document and input from Paul Giaconne I suggest the following interface: bool is_finite(); bool is_normal(); bool is_subnormal(); bool is_infinite(); bool is_plus_infinity(); bool is_minus_infinity(); bool is_nan(); bool is_quiet_nan(); bool is_signalling_nan(); The IEEE754 standard uses the term "denormal", but the draft for the next revision of the IEEE754 standard uses the term "subnormal", so "subnormal" is probably better. --Johan Råde
participants (3)
-
Johan Råde -
John Maddock -
Martin Bonner