Por que NaN - NaN == 0.0 com o compilador Intel C ++?


300

É sabido que os NaNs se propagam em aritmética, mas não consegui encontrar nenhuma demonstração, então escrevi um pequeno teste:

#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;
}

O exemplo ( rodando ao vivo aqui ) produz basicamente o que eu esperaria (o negativo é um pouco estranho, mas meio que faz sentido):

neg: -nan
sub: nan nan nan
add: nan nan
div: nan nan nan
mul: nan nan

MSVC 2015 produz algo semelhante. No entanto, o Intel C ++ 15 produz:

neg: -nan(ind)
sub: nan nan 0.000000
add: nan nan
div: nan nan nan
mul: nan nan

Especificamente qNaN - qNaN == 0.0.

Isso ... não pode estar certo, certo? O que os padrões relevantes (ISO C, ISO C ++, IEEE 754) dizem sobre isso e por que há uma diferença de comportamento entre os compiladores?


18
Javascript e Python (numpy) não têm esse comportamento. Nan-NaNé NaN. Perl e Scala também se comportam da mesma forma.
Paul

33
Talvez você tenha ativado otimizações matemáticas inseguras (o equivalente a -ffast-mathno gcc)?
Matteo Italia

5
@ nm: Não é verdade. Anexo F, que é opcional mas normativo quando suportada, e necessário para ter um comportamento de ponto flutuante especificado em tudo , essencialmente incorpora IEEE 754 em C.
R .. GitHub parar de ajudar ICE

5
Se você quiser perguntar sobre o padrão IEEE 754, mencione-o em algum lugar da pergunta.
n. 'pronomes' m.

68
Eu tinha certeza de que essa pergunta era sobre JavaScript no título.
MikeTheLiar

Respostas:


300

O manuseio de ponto flutuante padrão no compilador Intel C ++ é /fp:fast, o qual manipula NaNinseguros (o que também resulta em NaN == NaNser, truepor exemplo). Tente especificar /fp:strictou /fp:precisee veja se isso ajuda.


15
Eu só estava tentando isso. De fato, a especificação precisa ou estrita corrige o problema.
imallett

67
Eu gostaria de endossar a decisão da Intel de deixar o padrão /fp:fast: se você deseja algo seguro , é melhor evitar que os NaNs apareçam em primeiro lugar e geralmente não use ==com números de ponto flutuante. Confiar na semântica estranha que o IEEE754 atribui ao NaN está causando problemas.
precisa saber é o seguinte

10
@leftaroundabout: O que você acha estranho sobre o NaN, além da horrível decisão do IMHO de ter o NaN! = NaN retornar verdadeiro?
Supercat

21
Os NaNs têm usos importantes - eles podem detectar situações excepcionais sem exigir testes após cada cálculo. Nem todo desenvolvedor de ponto flutuante precisa deles, mas não os dispensa.
Bruce Dawson

6
@supercat Por curiosidade, você concorda com a decisão de NaN==NaNretornar false?
Kyle Strand

53

Este . . . não pode estar certo, certo? Minha pergunta: o que as normas relevantes (ISO C, ISO C ++, IEEE 754) dizem sobre isso?

Petr Abdulin já respondeu por que o compilador dá uma 0.0resposta.

Aqui está o que a IEEE-754: 2008 diz:

(6.2 Operações com NaNs) "[...] Para uma operação com entradas silenciosas de NaN, exceto operações máximas e mínimas, se um resultado de ponto flutuante for entregue, o resultado deve ser um NaN silencioso, que deve ser um dos NaNs de entrada ".

Portanto, o único resultado válido para a subtração de dois operandos NaN silenciosos é um NaN silencioso; qualquer outro resultado não é válido.

O Padrão C diz:

(C11, F.9.2 Transformações de expressão p1) "[...]

x - x → 0. 0 "As expressões x - x e 0. 0 não são equivalentes se x for um NaN ou infinito"

(onde aqui NaN denota um NaN silencioso conforme F.2.1p1 "Esta especificação não define o comportamento dos NaNs de sinalização. Geralmente usa o termo NaN para denotar NaNs silenciosos")


20

Como vejo uma resposta impedindo a conformidade com os padrões do compilador da Intel e ninguém mais mencionou isso, vou apontar que o GCC e o Clang têm um modo no qual fazem algo bastante semelhante. O comportamento padrão deles é compatível com 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

- mas se você pede velocidade às custas da correção, recebe o que pede -

$ 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

Eu acho que é inteiramente justo criticar a escolha do padrão da ICC , mas eu não leria toda a guerra do Unix nessa decisão.


Observe que -ffast-math, com , gccnão está mais em conformidade com a ISO 9899: 2011 em relação à aritmética de ponto flutuante.
fuz 1/09/09

1
@FUZxxl Sim, o ponto é que ambos os compiladores têm um modo de ponto flutuante não compatível, é que o icc é o padrão desse modo e o gcc não.
zwol 01/09/2015

4
Apenas para jogar combustível no fogo, eu realmente gosto da opção da Intel de permitir matemática rápida por padrão. O objetivo principal do uso de flutuadores é obter alto rendimento.
Navin
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.