Re: NaNs
* Jiang:
On Jul 29, 10:28 pm, "Alf P. Steinbach" <al...@start.no> wrote:
Correct testing, after having established IEEE floating point, is
if( x != x )
{
// This is a NaN
}
[snip]
Also, note that the IEEE 754 standard reportedly (I only have a draft of a later
standard) says, in its ?7.1, that "The invalid operation exception is signaled
if an operand is invalid for the operation to be performed. The result, when the
exception occurs without a trap, shall be a quiet NaN (6.2) provided the
destination has a floating-point format. The invalid operations are:
1. Any operation on a signaling NaN (6.2)"
Also it is quite possible optimizer will just ignore/remove such test.
It's always possible with an error in the compiler, rendering it non-conforming.
I fail to see the relevance of that to anything.
That argument is like, don't use 'main', or don't use 'int', because there could
be an error in the compiler that, uh, well, something.
Hey Alf:
I wish I emphasized this at the very beginning, what you've said is
true,
but the main point is how useful is it.
All your words are based on one *strong* assumption, that is, an
IEEE754
implementation is available for your above "correct test".
But, let's first go back to the reality first.
1. The current C++ standard simply ignores IEEE754. Add it will just
contribute to the amount of UBs, IMHO.
Oh, no, the C++ standard doesn't quite ignore IEEE754. It just refers to it via
another name, IEC ;-). When I wrote "after having established IEEE floating
point" I meant after checking std::numeric_limits<double>::is_iec559.
2. Even now the so-called IEEE754 conformable compiler does not exist.
(correct me if I am wrong)
Don't know, sorry. I guess Dave Abrahams would know since presumably they've
been up against this issue in Boost development. And, hey, Dave is with us in
this thread! :-)
But, at least the compilers I'm familiar with *claim* that they conform to
IEEE754, by having that 'is_iec559' set to 'true'.
If the compiler says that and still optimizes equality checks away so that it
changes the effect of the source code, then it's a compiler bug, and perhaps the
best response then is to report it to the compiler vendor.
3. Things are much different if we compare this issue with "don't use
'main'" or something like that. Without the specifications
in the holly standard, you/we can not call it an error.
the vender's can do whatever they want.
To prove my words, I find at least one optimizer does removes the
test you proposed, so it is real. For the following code,
$ cat op.cpp
#include <iostream>
bool is_nan(double x)
{
return (x != x) ? true : false;
}
int main()
{
double a = 0.0;
double b = 0.0;
std::cout << "0.0/0.0 is a NaN? : "
<< std::boolalpha << is_nan(a/b) << std::endl;
}
, if the floating point optimization is switched on, then
$ icl /fp:fast op.cpp
[...]
$ ./op
0.0/0.0 is a NaN? : false
Hm, there's no checking of IEEE 754 support in that program.
I don't have that compiler, but try the following program:
<code>
#include <iostream>
#include <limits>
typedef char CompilerSupportsIEEE[std::numeric_limits<double>::is_iec559];
bool isNaN( double x ) { return (x != x); }
int main()
{
using namespace std;
double a = 0.0;
double b = 0.0;
cout << "0.0/0.0 is a NaN? : " << boolalpha << isNaN( a/b ) << endl;
}
</code>
Also my DSP (ccs) compiler cl6x simply ignores the above
test even in debug build.
You may say the "over-optimization" violates IEEE754,
and they are not IEEE754 conformant, then what should
we do next?
Check for IEEE 754 conformance, e.g. as shown above (if the compiler supports
zero sized arrays as a language extension the above static assert may not
correctly yield any diagnostic, so better use e.g. Boost or Loki static assert).
So you see we poor programmers must face such a difficult
situation. Using your test will introduce strong
dependencies, for example, compiler version, optimization
options, and platform dependent issues, etc...
I don't think so. :-)
To restate my points:
1. We should stick to the implementation for this issue.
User code should not do such kind of testing.
2. If no implementation available, instead of testing
the possible NaN, try to prevent it.
3. If we can not prevent it, well, at least we can
crash the program [intentionally, same as some
fp exception default behaviors ].
4. If NaN test is a must, instead of using unreliable
assumption on IEEE754, snprintf&match the NaN's
symbol (for NaN, nan, etc..) is another way to
try. (well, other assumptions must be made)
I think these points describe a personal preference (not very arguable), and
anyway, I think arguments for or against would depend on the concrete situation.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]