Pourquoi NaN n'est-il pas égal à NaN ?

Question

La norme IEEE pertinente définit une constante numérique NaN (not a number) et prescrit que NaN doit être comparé comme non égal à lui-même. Pourquoi ?

Tous les langages que je connais appliquent cette règle. Mais elle cause souvent des problèmes importants, par exemple un comportement inattendu lorsque NaN est stocké dans un conteneur, lorsque NaN est dans les données qui sont triées, etc. Sans compter que la grande majorité des programmeurs s'attendent à ce que tout objet soit égal à lui-même (avant qu'ils n'apprennent l'existence de NaN), donc les surprendre ajoute aux bugs et à la confusion.

Les normes IEEE sont bien pensées, donc je suis sûr qu'il y a une bonne raison pour laquelle la comparaison de NaN comme égal à lui-même serait mauvaise. Je n'arrive tout simplement pas à savoir ce que c'est.

Edit : veuillez vous référer à Quelle est la raison pour laquelle toutes les comparaisons retournent faux pour les valeurs IEEE754 NaN ? comme la réponse qui fait autorité.

Answer 1

La réponse acceptée est 100% sans question FAUX. . Pas à moitié faux ou même légèrement faux. Je crains que ce problème n'embrouille et n'induise en erreur les programmeurs pendant longtemps encore lorsque cette question apparaîtra dans les recherches.

NaN est conçu pour se propager à travers tous les calculs, les infectant comme un virus, donc si quelque part dans vos calculs profonds et complexes vous tombez sur un NaN, vous ne sortez pas une réponse apparemment sensée. Sinon, par identité, NaN/NaN devrait être égal à 1, avec toutes les autres conséquences comme (NaN/NaN)==1, (NaN*1)==NaN, etc. Si vous imaginez que vos calculs se sont trompés quelque part (l'arrondi a produit un dénominateur nul, donnant NaN), etc., vous pourriez obtenir des résultats très incorrects (ou pire : subtilement incorrects) de vos calculs sans indication évidente de la raison.

Il y a aussi de très bonnes raisons d'utiliser des NaN dans les calculs lorsqu'on cherche la valeur d'une fonction mathématique ; l'un des exemples donnés dans le document lié est la recherche des zéros() d'une fonction f(). Il est tout à fait possible qu'en sondant la fonction avec des valeurs supposées, vous en sondiez une où la fonction f() ne donne aucun résultat sensé. Cela permet à zeros() de voir le NaN et de continuer son travail.

L'alternative à NaN est de déclencher une exception dès qu'une opération illégale est rencontrée (également appelé un signal ou un piège). Outre les pénalités de performance massives que vous pourriez rencontrer, il n'y avait à l'époque aucune garantie que les processeurs le supporteraient au niveau matériel ou que le système d'exploitation/langage le supporterait au niveau logiciel ; chacun était son propre flocon de neige dans la gestion de la virgule flottante. L'IEEE a décidé de le traiter explicitement dans le logiciel comme les valeurs NaN afin qu'il soit portable sur n'importe quel OS ou langage de programmation. Les algorithmes en virgule flottante corrects sont généralement corrects dans toutes les implémentations en virgule flottante. que ce soit node.js ou COBOL (hah).

En théorie, il n'est pas nécessaire de définir des directives #pragma spécifiques, d'activer des drapeaux de compilation farfelus, d'attraper les bonnes exceptions ou d'installer des gestionnaires de signaux spéciaux pour que ce qui semble être un algorithme identique fonctionne correctement. Malheureusement, certains concepteurs de langage et auteurs de compilateurs ont été très occupés à défaire cette fonctionnalité au mieux de leurs capacités.

Veuillez lire certaines des informations sur l'histoire de la virgule flottante IEEE 754. Aussi cette réponse sur une question similaire où un membre du comité a répondu : Quelle est la raison pour laquelle toutes les comparaisons retournent faux pour les valeurs IEEE754 NaN ?

"Un entretien avec le vieil homme du point flottant

"Histoire du format à virgule flottante de l'IEEE"

Ce que tout informaticien devrait savoir sur l'arithmétique à virgule flottante

Answer 2

Bien, log(-1) donne NaN y acos(2) donne également NaN . Est-ce que cela signifie que log(-1) == acos(2) ? De toute évidence, non. Il est donc parfaitement logique que NaN n'est pas égal à lui-même.

En réexaminant cette question presque deux ans plus tard, voici une fonction de comparaison "sûre pour NaN" :

function compare(a,b) {
    return a == b || (isNaN(a) && isNaN(b));
}

Answer 3

Ma réponse originale (d'il y a 4 ans) critique la décision d'un point de vue moderne sans comprendre le contexte dans lequel la décision a été prise. En tant que telle, elle ne répond pas à la question.

La réponse correcte est donnée aquí :

NaN != NaN est née de deux considérations pragmatiques :

[...] Il n'y avait pas isnan( ) à l'époque où NaN a été formalisé dans l'arithmétique 8087 ; il était nécessaire de fournir aux programmeurs un moyen pratique et efficace de détecter les valeurs NaN sans dépendre de langages de programmation fournissant quelque chose comme isnan( ) ce qui pourrait prendre plusieurs années

Cette approche présentait un inconvénient : elle rendait NaN moins utile dans de nombreuses situations sans rapport avec le calcul numérique. Par exemple, bien plus tard, lorsque les gens ont voulu utiliser NaN pour représenter les valeurs manquantes et les mettre dans des conteneurs basés sur le hachage, ils n'y sont pas parvenus.

Si la commission avait prévu des cas d'utilisation futurs et les avait jugés suffisamment importants, elle aurait pu opter pour la formule plus verbeuse suivante !(x<x & x>x) au lieu de x!=x comme un test pour NaN . Cependant, leur objectif était plus pragmatique et étroit : fournir la meilleure solution pour un calcul numérique, et en tant que tel, ils ne voyaient aucun problème dans leur approche.

\===

Réponse originale :

Je suis désolé, bien que j'apprécie la réflexion qui a été faite dans la réponse la plus votée, je ne suis pas d'accord avec elle. NaN ne signifie pas "indéfini" - cf. http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF page 7 (recherchez le mot "undefined"). Comme le confirme ce document, NaN est un concept bien défini.

De plus, l'approche de l'IEEE consistait à suivre les règles mathématiques régulières autant que possible, et lorsqu'elles ne le pouvaient pas, à suivre la règle de la "moindre surprise" - cf. https://stackoverflow.com/a/1573715/336527 . Tout objet mathématique est égal à lui-même, donc les règles mathématiques impliqueraient que NaN == NaN devrait être vrai. Je ne vois aucune raison valable et puissante de s'écarter d'un principe mathématique aussi important (sans parler des règles moins importantes de la trichotomie de comparaison, etc.)

En conséquence, ma conclusion est la suivante.

Les membres du comité IEEE n'ont pas réfléchi très clairement et ont fait une erreur. Comme très peu de gens ont compris l'approche du comité IEEE, ou se sont souciés de ce que la norme dit exactement à propos de NaN (à savoir : le traitement de NaN par la plupart des compilateurs viole de toute façon la norme IEEE), personne n'a tiré la sonnette d'alarme. Par conséquent, cette erreur est maintenant intégrée dans la norme. Il est peu probable qu'elle soit corrigée, car une telle correction casserait beaucoup de code existant.

Edit : Voici un poste d'une discussion très instructive. Remarque : pour avoir une vision impartiale, vous devez lire l'intégralité du fil de discussion, car Guido a un point de vue différent de celui de certains autres développeurs principaux. Cependant, Guido n'est pas personnellement intéressé par ce sujet, et suit largement les recommandations de Tim Peters. Si quelqu'un a les arguments de Tim Peters en faveur de NaN != NaN veuillez les ajouter dans les commentaires ; ils ont de bonnes chances de me faire changer d'avis.

Answer 4

Une propriété intéressante est : si x == x retourne false, alors x es NaN.

(on peut utiliser cette propriété pour vérifier si x es NaN ou pas.)

Answer 5

Essayez ça :

var a = 'asdf';
var b = null;

var intA = parseInt(a);
var intB = parseInt(b);

console.log(intA); //logs NaN
console.log(intB); //logs NaN
console.log(intA==intB);// logs false

Si intA == intB était vrai, cela pourrait vous amener à conclure que a==b, ce qui n'est clairement pas le cas.

Une autre façon de voir les choses est que NaN vous donne simplement des informations sur ce que quelque chose N'EST PAS, pas ce qu'il est. Par exemple, si je dis "une pomme n'est pas un gorille" et "une orange n'est pas un gorille", pouvez-vous en conclure que "une pomme" = "une orange" ?