«Vector <float> .Equals» doit-il être réflexif ou doit-il suivre la sémantique IEEE 754?

Lors de la comparaison des valeurs à virgule flottante pour l'égalité, il existe deux approches différentes:

• NaNn'étant pas égal à lui-même, ce qui correspond à la spécification IEEE 754 .
• NaNétant égal à lui-même, ce qui fournit la propriété mathématique de la réflexivité qui est essentielle à la définition d'une relation d'équivalence

Les types à virgule flottante IEEE intégrés en C # ( floatet double) suivent la sémantique IEEE pour ==et !=(et les opérateurs relationnels comme <) mais assurent la réflexivité pour object.Equals, IEquatable<T>.Equals(et CompareTo).

Considérons maintenant une bibliothèque qui fournit des structures vectorielles au-dessus de float/ double. Un tel type de vecteur surchargerait ==/ !=et remplacerait object.Equals/ IEquatable<T>.Equals.

Ce sur quoi tout le monde est d'accord, c'est que ==/ !=devrait suivre la sémantique de l'IEEE. La question est de savoir si une telle bibliothèque doit implémenter la Equalsméthode (qui est distincte des opérateurs d'égalité) d'une manière réflexive ou d'une manière qui correspond à la sémantique IEEE.

Arguments pour utiliser la sémantique IEEE pour Equals:

• Il suit IEEE 754

• C'est (peut-être beaucoup) plus rapide car il peut tirer parti des instructions SIMD

  J'ai posé une question distincte sur stackoverflow sur la façon dont vous exprimeriez l'égalité réflexive à l'aide d'instructions SIMD et leur impact sur les performances: instructions SIMD pour la comparaison d'égalité en virgule flottante

  Mise à jour: Il semble possible d'implémenter efficacement l'égalité réflexive à l'aide de trois instructions SIMD.

• La documentation de Equalsne nécessite pas de réflexivité lors de l'utilisation de virgule flottante:

  Les instructions suivantes doivent être vraies pour toutes les implémentations de la méthode Equals (Object). Dans la liste, x, yet zreprésentent des références d'objets qui ne sont pas nuls.

  x.Equals(x)renvoie true, sauf dans les cas qui impliquent des types à virgule flottante. Voir ISO / CEI / IEEE 60559: 2011, Technologies de l'information - Systèmes à microprocesseurs - Arithmétique à virgule flottante.

• Si vous utilisez des flottants comme clés de dictionnaire, vous vivez dans un état de péché et ne devez pas vous attendre à un comportement sain.

Arguments pour être réflexif:

• Il est compatible avec les types existants, y compris Single, Double, Tupleet System.Numerics.Complex.

  Je ne connais aucun précédent dans la BCL où Equalssuit IEEE au lieu d'être réflexif. Les exemples comprennent contre Single, Double, Tupleet System.Numerics.Complex.

• Equalsest principalement utilisé par les conteneurs et les algorithmes de recherche qui reposent sur la réflexivité. Pour ces algorithmes, un gain de performances n'est pas pertinent s'il les empêche de fonctionner. Ne sacrifiez pas l'exactitude à la performance.
• Il casse tous les ensembles à base de hachage et des dictionnaires, Contains, Find, IndexOfsur diverses collections / LINQ, ensemble des opérations de LINQ (base Union, Exceptetc.) si les données contiennent des NaNvaleurs.

• Le code qui effectue des calculs réels où la sémantique IEEE est acceptable fonctionne généralement sur des types concrets et utilise ==/ !=(ou des comparaisons epsilon plus probables).

  Actuellement, vous ne pouvez pas écrire de calculs haute performance à l'aide de génériques car vous avez besoin d'opérations arithmétiques pour cela, mais celles-ci ne sont pas disponibles via des interfaces / méthodes virtuelles.

  Une Equalsméthode plus lente n'affecterait donc pas la plupart des codes hautes performances.

• Il est possible de fournir une IeeeEqualsméthode ou une IeeeEqualityComparer<T>pour les cas où vous avez besoin de la sémantique IEEE ou si vous avez besoin d'un avantage en termes de performances.

À mon avis, ces arguments favorisent fortement une mise en œuvre réflexive.

L'équipe CoreFX de Microsoft prévoit d'introduire un tel type de vecteur dans .NET. Contrairement à moi, ils préfèrent la solution IEEE , principalement en raison des avantages de performance. Puisqu'une telle décision ne sera certainement pas modifiée après une version finale, je veux obtenir des commentaires de la communauté sur ce que je pense être une grosse erreur.

Je dirais que le comportement IEEE est correct. NaNs ne sont en aucun cas équivalents; ils correspondent à des conditions mal définies où une réponse numérique n'est pas appropriée.

Au-delà des avantages de performance qui découlent de l'utilisation de l'arithmétique IEEE que la plupart des processeurs prennent en charge nativement, je pense qu'il y a un problème sémantique à dire que si isnan(x) && isnan(y), alors x == y. Par exemple:

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

Je dirais qu'il n'y a aucune raison valable pour laquelle on considérerait xégal à y. Vous pourriez à peine conclure que ce sont des nombres équivalents; ce ne sont pas du tout des chiffres, donc cela semble être un concept totalement invalide.

De plus, du point de vue de la conception d'API, si vous travaillez sur une bibliothèque à usage général qui est destinée à être utilisée par de nombreux programmeurs, il est logique d'utiliser la sémantique à virgule flottante la plus typique de l'industrie. Le but d'une bonne bibliothèque est de gagner du temps pour ceux qui l'utilisent, donc la construction d'un comportement non standard est prête à confusion.

Il y a un problème: IEEE754 définit les opérations relationnelles et l'égalité d'une manière bien adaptée aux applications numériques. Il n'est pas adapté au tri et au hachage. Donc, si vous souhaitez trier un tableau en fonction de valeurs numériques, ou si vous souhaitez ajouter des valeurs numériques à un ensemble ou les utiliser comme clés dans un dictionnaire, vous déclarez que les valeurs NaN ne sont pas autorisées, ou vous n'utilisez pas IEEE754 opérations intégrées. Votre table de hachage devrait s'assurer que tous les NaN sont mis en correspondance avec la même valeur et être comparables les uns aux autres.

Si vous définissez Vector, vous devez décider si vous souhaitez l'utiliser uniquement à des fins numériques ou s'il doit être compatible avec le tri et le hachage. Je pense personnellement que l'objectif numérique devrait être beaucoup plus important. Si le tri / hachage est nécessaire, vous pouvez écrire une classe avec Vector en tant que membre et définir le hachage et l'égalité dans cette classe comme vous le souhaitez.