关于为什么NaN：为什么NaN-NaN == 0.0与英特尔C ++编译器？


Why does NaN - NaN == 0.0 with the Intel C++ Compiler?

众所周知，nan在算术上传播，但我找不到任何演示，所以我写了一个小测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#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
sub: %f %f %f
add: %f %f
div: %f %f %f
mul: %f %f
",
        neg, sub1,sub2,sub3, add1,add2, div1,div2,div3, mul1,mul2
    );

    return 0;
}

这个例子(在这里运行)基本上产生了我所期望的(负面的有点奇怪，但它有点道理)：

1
2
3
4
5
neg: -nan
sub: nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan

号

MSVC 2015生产了类似的产品。然而，英特尔C++ 15产生：

1
2
3
4
5
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)对此表示什么，为什么编译器之间的行为有差异？

相关讨论

英特尔C++编译器中的默认浮点处理是EDOCX1×0，它不安全地处理EDCOX1×1的引用(这也导致EDCOX1×2是EDCOX1×3)。尝试指定/fp:strict或/fp:precise，看看是否有帮助。

相关讨论

这个。…不可能是对的，对吧？我的问题是：相关标准(ISO C、ISO C++、IEEE 754)对此有何看法？

PetrAbdulin已经回答了为什么编译器给出了0.0的答案。

以下是IEEE-754:2008所说的：

(6.2 Operations with NaNs)"[...] For an operation with quiet NaN inputs, other than maximum and minimum operations, if a floating-point result is to be delivered the result shall be a quiet NaN which should be one of the input NaNs."

号

因此，两个安静NaN操作数的减法的唯一有效结果是一个安静NaN；任何其他结果都无效。

C标准规定：

(C11, F.9.2 Expression transformations p1)"[...]

x ? x → 0. 0"The expressions x ? x and 0. 0 are not equivalent if x is a NaN or
infinite"

号

(此处，NaN表示F.2.1p1中的安静NaN，"本规范未定义信号NaN的行为。它通常使用术语nan表示安静的nan")。

因为我看到了一个指责英特尔编译器标准遵从性的答案，而没有其他人提到过这一点，我将指出GCC和Clang都有一种模式，在这种模式下，它们可以做一些非常相似的事情。它们的默认行为符合IEEE-

1
2
3
4
5
6
7
8
9
10
11
12
13
$ 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

-但是如果你以牺牲正确性为代价要求速度，你就会得到你所要求的-

1
2
3
4
5
6
7
8
9
10
11
12
13
$ 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战争重新解读成这个决定。

相关讨论