为什么使用英特尔 C++ 编译器时 NaN - NaN == 0.0？
众所周知，NaN 在算术中传播，但是我找不到任何演示，所以我写了一个小测试：
#include <limits>
#include <cstdio>
int main(int argc, char* argv[]) {
float qNaN = std::numeric_limits<float>::quiet_NaN();
float neg = -qNaN;
float sub1 = 6.0f - qNaN;
float sub2 = qNaN - 6.0f;
float sub3 = qNaN - qNaN;
float add1 = 6.0f + qNaN;
float add2 = qNaN + qNaN;
float div1 = 6.0f / qNaN;
float div2 = qNaN / 6.0f;
float div3 = qNaN / qNaN;
float mul1 = 6.0f * qNaN;
float mul2 = qNaN * qNaN;
printf(
"neg: %f\nsub: %f %f %f\nadd: %f %f\ndiv: %f %f %f\nmul: %f %f\n",
neg, sub1,sub2,sub3, add1,add2, div1,div2,div3, mul1,mul2
);
return 0;
}
示例 (running live here) 基本上产生了我所期望的结果（否定有点奇怪，但它有点道理）：
neg: -nan
sub: nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan
MSVC 2015 产生类似的东西。但是，英特尔 C++ 15 会产生：
neg: -nan(ind)
sub: nan nan 0.000000
add: nan nan
div: nan nan nan
mul: nan nan
具体来说，qNaN - qNaN == 0.0。
这……不可能吧？相关标准（ISO C、ISO C++、IEEE 754）对此有何评论，为什么编译器之间的行为会有所不同？
Nan-NaN 是 NaN。 Perl 和 Scala 的行为也类似。
-ffast-math）？
英特尔 C++ 编译器中的默认浮点处理是 /fp:fast，它不安全地处理 NaN（这也导致 NaN == NaN 成为 true）。尝试指定 /fp:strict 或 /fp:precise 看看是否有帮助。
这个 。 . .不可能是对的，对吧？我的问题：相关标准（ISO C、ISO C++、IEEE 754）对此有何评论？
Petr Abdulin 已经回答了为什么编译器会给出 0.0 答案。
这是 IEEE-754:2008 所说的：
（6.2 使用 NaN 的运算）“[...] 对于具有安静 NaN 输入的运算，除了最大和最小运算之外，如果要传递浮点结果，则结果应该是安静的 NaN，它应该是输入 NaN。”
因此，两个安静的 NaN 操作数相减的唯一有效结果是安静的 NaN；任何其他结果均无效。
C标准说：
(C11, F.9.2 表达式转换 p1) “[...] x - x → 0. 0 “如果 x 是 NaN 或无穷大，则表达式 x - x 和 0. 0 不等价”
（这里的 NaN 表示根据 F.2.1p1 的安静 NaN “本规范没有定义信号 NaN 的行为。它通常使用术语 NaN 来表示安静的 NaN”）
由于我看到了一个质疑英特尔编译器的标准合规性的答案，而没有其他人提到这一点，我将指出 GCC 和 Clang 都有一种模式，它们在其中做一些非常相似的事情。它们的默认行为符合 IEEE —
$ g++ -O2 test.cc && ./a.out
neg: -nan
sub: nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan
$ clang++ -O2 test.cc && ./a.out
neg: -nan
sub: -nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan
——但如果你以牺牲正确性为代价来要求速度，你就会得到你所要求的——
$ g++ -O2 -ffast-math test.cc && ./a.out
neg: -nan
sub: nan nan 0.000000
add: nan nan
div: nan nan 1.000000
mul: nan nan
$ clang++ -O2 -ffast-math test.cc && ./a.out
neg: -nan
sub: -nan nan 0.000000
add: nan nan
div: nan nan nan
mul: nan nan
我认为批评 ICC 的默认选择是完全公平的，但我不会将整个 Unix 战争重新解读为该决定。
-ffast-math，gcc 在浮点运算方面不再符合 ISO 9899:2011。
/fp:fast的决定：如果您想要 安全 的东西，您最好一开始就避免出现 NaN，并且通常不要使用==与浮点数。依靠 IEEE754 分配给 NaN 的奇怪语义是自找麻烦。NaN==NaN返回false的决定？