首页 文章

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

提问于
浏览 次
292

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

#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）对此有何评论，为什么编译器之间的行为存在差异？

c++ c floating-point ieee-754 icc

3 回答

  • 52

    英特尔C编译器中的默认浮点处理是 /fp:fast ，它不安全地处理 NaN （例如，这也导致 NaN == NaN 为 true ） . 尝试指定 /fp:strict 或 /fp:precise ，看看是否有帮助 .

    回复于
  • 18

    这个 . . . 不能对，对吧？我的问题：相关标准（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”）

    回复于
  • 295

    由于我看到一个回答强调英特尔编译器的标准符合性，并且没有其他人提到这一点，我将指出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战争重新纳入该决定 .

    回复于

相关问题