¿Debería `Vector <float> .Equals` ser reflexivo o debería seguir la semántica IEEE 754?

Al comparar valores de coma flotante para igualdad, hay dos enfoques diferentes:

• NaNno es igual a sí mismo, lo que coincide con la especificación IEEE 754 .
• NaNser igual a sí mismo, lo que proporciona la propiedad matemática de la reflexividad que es esencial para la definición de una relación de equivalencia

Los tipos de punto flotante IEEE integrados en C # ( floaty double) siguen la semántica IEEE para ==y !=(y los operadores relacionales como <) pero aseguran la reflexividad para object.Equals, IEquatable<T>.Equals(y CompareTo).

Ahora considere una biblioteca que proporciona estructuras vectoriales sobre float/ double. Tal tipo de vector sobrecargaría ==/ !=y anularía object.Equals/ IEquatable<T>.Equals.

En lo que todos están de acuerdo es que ==/ !=debería seguir la semántica de IEEE. La pregunta es, si dicha biblioteca implementa el Equalsmétodo (que está separado de los operadores de igualdad) de una manera reflexiva o que coincida con la semántica IEEE.

Argumentos para usar la semántica IEEE para Equals:

• Sigue a IEEE 754

• Es (posiblemente mucho) más rápido porque puede aprovechar las instrucciones SIMD

  He hecho una pregunta por separado sobre stackoverflow sobre cómo expresaría la igualdad reflexiva utilizando las instrucciones SIMD y su impacto en el rendimiento: instrucciones SIMD para la comparación de igualdad de punto flotante

  Actualización: Parece que es posible implementar la igualdad reflexiva de manera eficiente utilizando tres instrucciones SIMD.

• La documentación para Equalsno requiere reflexividad cuando involucra punto flotante:

  Las siguientes declaraciones deben ser ciertas para todas las implementaciones del método Equals (Object). En la lista, x, y, y zrepresentan referencias a objetos que no son nulos.

  x.Equals(x)retornos true, excepto en casos que involucran tipos de punto flotante. Ver ISO / IEC / IEEE 60559: 2011, Tecnología de la información - Sistemas de microprocesador - Aritmética de punto flotante.

• Si usa flotadores como teclas de diccionario, está viviendo en un estado de pecado y no debe esperar un comportamiento sensato.

Argumentos para ser reflexivo:

• Es compatible con los tipos existentes, incluyendo Single, Double, Tupley System.Numerics.Complex.

  No conozco ningún precedente en el BCL donde Equalssiga IEEE en lugar de ser reflexivo. Contraejemplos incluyen Single, Double, Tupley System.Numerics.Complex.

• Equalses utilizado principalmente por contenedores y algoritmos de búsqueda que dependen de la reflexividad. Para estos algoritmos, una ganancia de rendimiento es irrelevante si les impide funcionar. No sacrifique la corrección por el rendimiento.
• Rompe todos los conjuntos y diccionarios en base de hash, Contains, Find, IndexOfen varias colecciones / LINQ, LINQ operaciones de conjunto basada ( Union, Except, etc.) si los datos contienen NaNvalores.

• El código que realiza cálculos reales donde IEEE semántico es aceptable generalmente funciona en tipos y usos concretos ==/ !=(o más probablemente en comparaciones épsilon).

  Actualmente no puede escribir cálculos de alto rendimiento utilizando genéricos, ya que necesita operaciones aritméticas para eso, pero estos no están disponibles a través de interfaces / métodos virtuales.

  Por lo tanto, un Equalsmétodo más lento no afectaría a la mayoría de los códigos de alto rendimiento.

• Es posible proporcionar un IeeeEqualsmétodo o IeeeEqualityComparer<T>para los casos en los que necesita la semántica IEEE o necesita una ventaja de rendimiento.

En mi opinión, estos argumentos favorecen fuertemente una implementación reflexiva.

El equipo CoreFX de Microsoft planea introducir dicho tipo de vector en .NET. A diferencia de mí , prefieren la solución IEEE , principalmente debido a las ventajas de rendimiento. Dado que tal decisión ciertamente no cambiará después de un lanzamiento final, quiero recibir comentarios de la comunidad, sobre lo que creo que es un gran error.

Yo diría que el comportamiento de IEEE es correcto. NaNs no son equivalentes entre sí de ninguna manera; corresponden a condiciones mal definidas donde una respuesta numérica no es apropiada.

Más allá de los beneficios de rendimiento que provienen del uso de la aritmética IEEE que la mayoría de los procesadores admiten de forma nativa, creo que hay un problema semántico al decir que si isnan(x) && isnan(y), entonces x == y. Por ejemplo:

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

Yo diría que no hay una razón significativa por la que uno consideraría xigual a y. Difícilmente podría concluir que son números equivalentes; no son números en absoluto, por lo que parece un concepto completamente inválido.

Además, desde una perspectiva de diseño de API, si está trabajando en una biblioteca de propósito general que está destinada a ser utilizada por muchos programadores, tiene sentido usar la semántica de punto flotante más típica de la industria. El objetivo de una buena biblioteca es ahorrar tiempo para quienes la usan, por lo que construir un comportamiento no estándar está listo para la confusión.

Hay un problema: IEEE754 define las operaciones relacionales y la igualdad de una manera adecuada para aplicaciones numéricas. No es adecuado para la clasificación y el hash. Entonces, si desea ordenar una matriz basada en valores numéricos, o si desea agregar valores numéricos a un conjunto o usarlos como claves en un diccionario, declara que los valores NaN no están permitidos o no usa IEEE754 operaciones integradas. Su tabla hash tendría que asegurarse de que todos los NaN coincidan con el mismo valor y compararlos entre sí.

Si define Vector, debe tomar la decisión de diseño si desea usarlo solo con fines numéricos o si debe ser compatible con la clasificación y el hash. Personalmente, creo que el propósito numérico debería ser mucho más importante. Si se necesita la clasificación / hashing, puede escribir una clase con Vector como miembro y definir el hashing y la igualdad en esa clase de la manera que desee.