NaN == NaN?

[rüdiger]

@Dravere
die meisten Menschen dürften

if(isnan(f)) {
 ...
}

deutlich leserlicher finden, als

if(!(f == f)) {
  ...
}

.

Wie man allein am Ergebnis der Umfrage sieht :).

[Dravere]

@rüdiger,
Ehm wie? Was soll der zweite Code denn bedeuten? Ich meinte eher sowas:

if(val == Double.NaN)
{
}

// statt:
if(Double.IsNaN(val))
{
}

// bzw. der Vergleich auf IsNotNaN:
if(val != Double.NaN)
{
}

// statt:
if(!Double.IsNaN(val))
{
}

// Also hier ist doch wirklich das erstere lesbarer.

Ich finde einfach diese zusätzlich benötigte Funktion einen Unsinn. Wozu eine zusätzlich Funktion, wenn man schon Vergleiche hat?

Und was die Umfrage aussagt, halte ich für sehr fragwürdig. Ich hätte nämlich fast das angekreuzt, was richtig ist, statt das, was ich besser empfinden würde. Ich frage mich daher, bei wievielen dieser Fehler tatsächlich passiert ist. Meistens lesen die Leute nur die Umfrage und die Antworten, stimmen dann ab und lesen erst dann den ersten Beitrag.

Grüssli

[freaky]

Für mich ist NaN == NaN -> true. Ich finde ihr denkt viel zu logisch und bringt Beispiele, die damit nichts zu tuen haben. Gefragt ist einfach, Not a Number == Not a Number und das ist für mich true. Ihr setzt wiederrum Sachen für Not a Number ein. Keine Nummer ist keine Nummer.
Meine Meinung nunmal :p

[volkard]

FreakY<3Cpp schrieb:

Für mich ist NaN == NaN -> true. Ich finde ihr denkt viel zu logisch und bringt Beispiele, die damit nichts zu tuen haben. Gefragt ist einfach, Not a Number == Not a Number und das ist für mich true. Ihr setzt wiederrum Sachen für Not a Number ein. Keine Nummer ist keine Nummer.
Meine Meinung nunmal :p

Deswegen sind solche Abstimmungen auch Unfug.
Für viele ist auch intuitiv 0.9999999(unendlich viele neunen)!=1.0000000(unendlich viele nullen).
NaN==NaN bewertet man intuitiv richtig, wenn man weiß, was NaN ist. Ich lag bei inf==inf daneben, weil ich nicht wußte, was die Fließkommazahlenbauer mit inf gemeint hatten. Anscheinend kein silent error.

[flußKommaPunkt]

Gregor schrieb:

Ohne es zu testen und weiter zu lesen...

Evaluiert doch bitte mal in eurem Kopf den Ausdruck in der Frage und gebt die Antwort an. Dabei handelt es sich in der Fragestellung um den Vergleich zweier Fließkommawerte.

Wenn es sich um Fließkommawerte handelt, dann ist NaN == NaN.

[NaNology]

Evaluiert man NaN == Nan zu true, kann es sehr leicht passieren, dass mitten in einer FP-Berechnung Unsinn passiert, eine Variable den Wert NaN annimmt, aber durch irgendeinen für die Berechnung notwendigen Vergleich diese Unsinnigkeit unter den Tisch gekehrt wird und der Anwender sich wundert, warum bei Apfel / Birne plötzlich 0 rauskommt, anstatt einer Fehlermeldung.

[rapso]

Dravere schrieb:

Ich finde einfach diese zusätzlich benötigte Funktion einen Unsinn. Wozu eine zusätzlich Funktion, wenn man schon Vergleiche hat?

wozu noch extra constants wenn man a!=a benutzen kann?

[Dravere]

rapso schrieb:

Dravere schrieb:

Ich finde einfach diese zusätzlich benötigte Funktion einen Unsinn. Wozu eine zusätzlich Funktion, wenn man schon Vergleiche hat?

wozu noch extra constants wenn man a!=a benutzen kann?

Weil das wahnsinnig verwirrend ist. Jeder, welcher sowas liest, denkt sich im ersten Moment: "WTF???". Es stört somit den Lesefluss. Womöglich fällt dem Leser am Ende gar nicht auf, dass hier auf NaN geprüft wird, vor allem wenn kein zusätzlicher Kommentar dortsteht.

Grüssli

[Bitte ein Bit]

Ich schätze mal dass die Umfrage eher das Thema aufwerfen sollte wie einzelne Compiler eine Abfrage der Form (Nan == Nan) implementiert haben und nicht ob Nan == Nan ist.

Aus programmiertechnischer Sicht ist die Frage ob Nan == Nan ist Unfug. Denn ein Nan entsteht nur durch einen Rechenfehler und das Ergebnis ist ein Fehlerflag genannt Nan. Bei einem Vergleich von a=Nan,b=Nan wären viele Implementationen denkbar. Ein Compiler könnte bei einer Abfrage a==b einfach ein Vergleich der Speicherinhalte machen. Das Ergebnis wäre true. Ein andere Compiler würde hier vielleicht sogar ein Fehlermeldung der Form "Unhandeld Exception in ..." ausgeben. Ein anderer Compiler könnte auch den Rückgabewert ebenfalls auf Nan setzen. Denkbar wäre alles.

Mit dem folgenden Code bringe ich es sogar fertig dass einmal Nan==Nan true ist und einmal false ist.

double a = 1;
double b = 2;
double Diff;
bool equal1;
bool equal2;

a /= 0.0;
b /= 0.0;

Diff = (a - b);
equal1 = (fabs(Diff) < 0.1); // oder == 0.0 für exakten Vergleich
equal2 = (a == b);

Alles nur eine Frage wie a == b implementiert ist.

Also definiere ich:
Nan == Nan ist undefiniert

[knivil]

FreakY<3Cpp schrieb:

Für mich ist NaN == NaN -> true. Ich finde ihr denkt viel zu logisch und bringt Beispiele, die damit nichts zu tuen haben. Gefragt ist einfach, Not a Number == Not a Number und das ist für mich true. Ihr setzt wiederrum Sachen für Not a Number ein. Keine Nummer ist keine Nummer.
Meine Meinung nunmal

Aehm, allein vom Sprachgebrauch ist das quatsch. Ein Auto ist auch keine Nummer, also "Not a Number". Ein Telefon ist auch keine Nummer, also "Not a Number". Nun soll Telefon == Auto sein? Not a Number schliesst nur aus, dass es keine Nummer ist. Sprachlich stoesst man also auf Inkonsistenten.

Wieso spezielle extra Funktionen einführen

Normalerweise sind zwei Elemente x und y genau dann gleich, wenn x <= y und y <= x gilt. Nun kann man sich z.B. fragen, was denn 5 <= NaN ist? Ich vergleiche eine Nummer mit Not a Number. Logisch stoesst man also auf Inkonsistenten.

[Gast]

Bitte ein Bit schrieb:

Mit dem folgenden Code bringe ich es sogar fertig dass einmal Nan==Nan true ist und einmal false ist.

double a = 1;
double b = 2;
double Diff;
bool equal1;
bool equal2;

a /= 0.0;
b /= 0.0;

Diff = (a - b);
equal1 = (fabs(Diff) < 0.1); // oder == 0.0 für exakten Vergleich
equal2 = (a == b);

Errrrm, nein. a ist inf, b ist inf. inf == inf gilt. Diff ist NaN weil Inf - Inf.

[pumuckl]

Mit op== vergleicht man die Werte zweier Variablen und/oder Konstanten. NaN ist aber die Darstellung von "hat keinen Wert". => nicht vergleichbar, kann also nicht true sein. Eigentlich genausowenig false, aber es ist das kleinere Übel. Vorbedingung für op== sollte daher sein, dass keiner von beiden Werten NaN ist.
Nur wie überprüft man das? mit (x != NaN). Das sollte true geben, es sei denn x IST NaN.
Ergibt:
NaN != NaN -> false
NaN == NaN -> false

Klingt komisch, ist aber so (sollte so sein imo)...

[mngbd]

pumuckl schrieb:

Mit op== vergleicht man die Werte zweier Variablen und/oder Konstanten. NaN ist aber die Darstellung von "hat keinen Wert". => nicht vergleichbar, kann also nicht true sein. Eigentlich genausowenig false, aber es ist das kleinere Übel. Vorbedingung für op== sollte daher sein, dass keiner von beiden Werten NaN ist.

NaN ist sehr wohl ein Wert, nur eben keine Zahl. In C++ muss man solche Bockssprünge machen. In C hat man's leicht: == vergleicht zwei Zahlen. Bei Dingen, die keine Zahl sind, darf es ruhig anders reagieren.

Edit: Grammatik

[Christoph]

Etwas unschön finde ich, dass aus dem Grund std::sort auf Fließkomma-Sequenzen nicht benutzbar ist. Das sind ziemlich hohe Kosten, nur um (NaN != NaN) == true zu haben.

[Shade Of Mine]

Christoph schrieb:

Etwas unschön finde ich, dass aus dem Grund std::sort auf Fließkomma-Sequenzen nicht benutzbar ist. Das sind ziemlich hohe Kosten, nur um (NaN != NaN) == true zu haben.

Wo würdest du denn NaN hinschieben?

Ist NaN kleiner als 7? Oder größer als -5?
NaN kann man nicht sortieren, also einfach remove_if und gut ist.

[Gast]

Shade Of Mine schrieb:

Wo würdest du denn NaN hinschieben?

Ist NaN kleiner als 7? Oder größer als -5?
NaN kann man nicht sortieren, also einfach remove_if und gut ist.

Natürlich kann man NaN sortieren, man muss halt ein Kriterium definieren. Z.B. Matlab macht das imho richtige und sortiert alle NaN ans Ende.

[knivil]

Schreibe dir doch einen separate Vergleichsfunktion ... Ich sehe da kein Problem.

[Shade Of Mine]

Tim schrieb:

Natürlich kann man NaN sortieren, man muss halt ein Kriterium definieren. Z.B. Matlab macht das imho richtige und sortiert alle NaN ans Ende.

klar, das geht natürlich auch. je nach situation ist ein nan aber ein fehler und sollte explizit behandelt werden. aber ja, mein punkt war eher, dass christoph meinte sort ginge nicht und ich wollte ihm zeigen dass sort logisch auch bei (nan==nan)==true nicht gehen würde. (es sei denn man definiert sich eigene rahmenbedinungen)

[Christoph]

Shade Of Mine schrieb:

Christoph schrieb:

Etwas unschön finde ich, dass aus dem Grund std::sort auf Fließkomma-Sequenzen nicht benutzbar ist. Das sind ziemlich hohe Kosten, nur um (NaN != NaN) == true zu haben.

Wo würdest du denn NaN hinschieben?

Ist NaN kleiner als 7? Oder größer als -5?

Das hängt vom Programm ab. Sinnvoll wäre vermutlich ganz vorne oder ganz hinten.

knivil schrieb:

Schreibe dir doch einen separate Vergleichsfunktion ... Ich sehe da kein Problem.

Eine eigene Vergleichsfunktion hat zwei Nachteile:
1. Sie ist mehr Implementierungsaufwand und mehr Code, der gewartet werden muss.
2. Sie ist langsamer verglichen mit einem reinen Vergleich in Hardware.

Ich bin kein Numeriker, aber sortierbar zu sein halte ich für eine wünschenswerte Eigenschaft. Und wenn NaN eben ganz hinten landet, dann ist das denke ich besser, als wenn die Sortier-Funktion in eine Endlos-Schleife geht, nur weil man remove_if oder die eigene Vergleichsfunktion vergessen hat. Das ganze NaN-Verhalten ist IMHO eine Verletzung des "Principle of least astonishment".

NaNs sind infektiös: Wenn irgendwo in einem Ausdruck NaN auftaucht, taucht am Ende wahrscheinlich auch NaN auf. Und aus dem NaN bekommt man erschreckend wenig Information. Man erfährt im Grunde nur "irgendwas ist schiefgegangen". Ob es sqrt(negative_zahl) oder Division durch 0 oder was auch immer war, erfährt man nicht.
Wären aus heutiger Sicht C++-Exceptions (oder analoge Konzepte in anderen Sprachen) vielleicht geeigneter, weil man damit mehr Information über den aufgetretenen Fehler übermitteln kann?

[Gast]

Christoph schrieb:

Und aus dem NaN bekommt man erschreckend wenig Information. Man erfährt im Grunde nur "irgendwas ist schiefgegangen". Ob es sqrt(negative_zahl) oder Division durch 0 oder was auch immer war, erfährt man nicht.

Man könnte ja in NaNs mehrere NaN-Zustände kodieren (2^23 - 1 bei einem IEEE 754 single). Wird z.B. für die Unterscheidung signaling/silent NaNs schon benutzt. Aber wirklich Sinn macht das ja auch nicht.