O `Vector <float> .Equals` deve ser reflexivo ou deve seguir a semântica da IEEE 754?

Ao comparar valores de ponto flutuante para igualdade, existem duas abordagens diferentes:

• NaNnão sendo igual a si próprio, o que corresponde à especificação IEEE 754 .
• NaNsendo igual a si mesmo, o que fornece a propriedade matemática da Reflexividade, essencial para a definição de uma relação de Equivalência

Os construídas em IEEE flutuante tipos de ponto em C # ( floate double) acompanhar semântica para IEEE ==e !=(e os operadores relacionais como <) mas assegurar reflexividade para object.Equals, IEquatable<T>.Equals(e CompareTo).

Agora considere uma biblioteca que fornece estruturas vetoriais sobre float/ double. Esse tipo de vetor sobrecarregaria ==/ !=e substituía object.Equals/ IEquatable<T>.Equals.

O que todo mundo concorda é que ==/ !=deve seguir a semântica do IEEE. A questão é: essa biblioteca deve implementar o Equalsmétodo (que é separado dos operadores de igualdade) de maneira reflexiva ou de acordo com a semântica do IEEE.

Argumentos para usar a semântica IEEE para Equals:

• Segue IEEE 754

• É (possivelmente muito) mais rápido, porque pode tirar proveito das instruções do SIMD

  Fiz uma pergunta separada no stackoverflow sobre como você expressaria igualdade reflexiva usando instruções SIMD e seu impacto no desempenho: instruções SIMD para comparação de igualdade de ponto flutuante

  Atualização: parece possível implementar a igualdade reflexiva com eficiência usando três instruções SIMD.

• A documentação para Equalsnão requer reflexividade ao envolver ponto flutuante:

  As instruções a seguir devem ser verdadeiras para todas as implementações do método Equals (Object). Na lista, x, y, e zrepresentam referências a objetos que não são nulos.

  x.Equals(x)retorna true, exceto nos casos que envolvem tipos de ponto flutuante. Consulte ISO / IEC / IEEE 60559: 2011, Tecnologia da informação - Sistemas de microprocessadores - Aritmética de ponto flutuante.

• Se você estiver usando carros alegóricos como chaves de dicionário, estará vivendo um estado de pecado e não deve esperar um comportamento sensato.

Argumentos para ser reflexivo:

• É consistente com os tipos existentes, incluindo Single, Double, Tuplee System.Numerics.Complex.

  Eu não conheço nenhum precedente na BCL onde Equalssegue o IEEE em vez de ser reflexivo. Contra-exemplos incluem Single, Double, Tuplee System.Numerics.Complex.

• Equalsé usado principalmente por contêineres e algoritmos de busca que dependem da reflexividade. Para esses algoritmos, um ganho de desempenho é irrelevante se os impedir de funcionar. Não sacrifique a correção pelo desempenho.
• Rompe todos os conjuntos de hash base e dicionários, Contains, Find, IndexOfem várias colecções / LINQ, operações conjunto baseado LINQ ( Union, Except, etc.), se os dados contém NaNvalores.

• O código que faz cálculos reais em que a semântica do IEEE é aceitável geralmente funciona em tipos concretos e usa ==/ !=(ou comparações epsilon mais prováveis).

  Atualmente, não é possível gravar cálculos de alto desempenho usando genéricos, pois você precisa de operações aritméticas para isso, mas elas não estão disponíveis por meio de interfaces / métodos virtuais.

  Portanto, um Equalsmétodo mais lento não afetaria a maioria dos códigos de alto desempenho.

• É possível fornecer um IeeeEqualsmétodo ou um IeeeEqualityComparer<T>para os casos em que você precisa da semântica IEEE ou da vantagem de desempenho.

Na minha opinião, esses argumentos favorecem fortemente uma implementação reflexiva.

A equipe CoreFX da Microsoft planeja introduzir esse tipo de vetor no .NET. Ao contrário de mim, eles preferem a solução IEEE , principalmente devido às vantagens de desempenho. Como essa decisão certamente não será alterada após o lançamento final, quero receber feedback da comunidade sobre o que acredito ser um grande erro.

Eu diria que o comportamento do IEEE está correto. NaNs não são equivalentes entre si de forma alguma; eles correspondem a condições mal definidas onde uma resposta numérica não é apropriada.

Além dos benefícios de desempenho que vêm usando IEEE aritmética que a maioria dos processadores suportam nativamente, eu acho que há um problema de semântica com a dizer que se isnan(x) && isnan(y), então x == y. Por exemplo:

// C++
double inf = std::numeric_limits<double>::infinity();
double x = 0.0 / 0.0;
double y = inf - inf;

Eu argumentaria que não há uma razão significativa pela qual alguém considere xigual y. Você dificilmente poderia concluir que eles são números equivalentes; eles não são números, então parece um conceito totalmente inválido.

Além disso, do ponto de vista do design da API, se você estiver trabalhando em uma biblioteca de uso geral que se destina a ser usada por muitos programadores, faz sentido usar a semântica de ponto flutuante mais típica do setor. O objetivo de uma boa biblioteca é economizar tempo para quem a usa, portanto, criar comportamentos fora do padrão está pronto para confusão.

Há um problema: o IEEE754 define operações relacionais e igualdade de uma maneira adequada para aplicativos numéricos. Não é adequado para classificação e hash. Portanto, se você deseja classificar uma matriz com base em valores numéricos, ou se deseja adicionar valores numéricos a um conjunto ou usá-los como chaves em um dicionário, declara que os valores NaN não são permitidos ou não utiliza IEEE754 operações integradas. Sua tabela de hash precisaria garantir que todos os NaNs correspondessem ao mesmo valor e comparassem entre si.

Se você definir Vector, deverá tomar a decisão de design se deseja usá-lo apenas para fins numéricos ou se deve ser compatível com classificação e hash. Pessoalmente, acho que o objetivo numérico deve ser muito mais importante. Se a classificação / hash for necessária, você poderá escrever uma classe com Vector como membro e definir o hash e a igualdade nessa classe da maneira que desejar.