NaN == NaN?

Gregor

Umfrage: NaN == NaN?

Auswahl	Stimmen	Prozent
true	29	29.3%
false	70	70.7%

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.

PS: Es interessieren mich in dieser Umfrage Meinungen und nicht das tatsächliche Verhalten, das man irgendwo nachlesen kann.

Borschtsch

Ich dachte zuerst an eine Exception, also weder true noch false. Aber so tippe ich auf false, weil mir die Auswirkungen bei true irgendwie fataler erscheinen.

abc.w

Ich würde spontan sagen, true...

39 Stimmen auf false und noch keiner hatte Lust mal zu erläutern?

SeppJ

TravisG schrieb:

39 Stimmen auf false und noch keiner hatte Lust mal zu erläutern?

Was gibts da zu erläutern? Einfaches Gegenbeispiel:
Auto keine Zahl NaN
Telefon keine Zahl NaN
Auto == Telefon? false
NaN == NaN ist im Allgemeinen false

Christoph

SeppJ schrieb:

TravisG schrieb:

39 Stimmen auf false und noch keiner hatte Lust mal zu erläutern?

Was gibts da zu erläutern? Einfaches Gegenbeispiel:
Auto keine Zahl NaN
Telefon keine Zahl NaN
Auto == Telefon? false
NaN == NaN ist im Allgemeinen false

Auto -> Farbe -> Rot
Auto -> Farbe -> Blau

Auto == Auto -> true
-> Rot == Blau ist true

Ne, so geht das nicht.
In der mathematischen Logik fordert man normalerweise sogar an grundlegendster Stelle, dass x == x immer wahr ist, egal was für einen Typ oder Wert x auch haben mag. NaN != NaN ist also sehr "unmathematisch", in gewisser Weise.

knivil

x == x immer wahr ist, egal was für einen Typ oder Wert x auch haben mag

Ja, das mag sein. Jedoch hat x einen Typ, waehrend ich NaN als Wert interpretiere. Bei x == x ist auf der rechten Seite ja der gleiche Typ wie auf der linken. Somit besteht kein Problem. Was ist aber wenn die Typen der beiden NaN-Werte unterschiedlich sind. In Haskell kann der Vergleichsoperator auf leere Listen (aehnlich NaN) unterschiedlichen Typs nicht anwendet werden.

([] :: [Char]) == ([] :: [Int])

=> Error

Dravere

TravisG schrieb:

39 Stimmen auf false und noch keiner hatte Lust mal zu erläutern?

Ich frage mich, wieviele hier nicht das angekreuzt haben, was das richtige Verhalten ist, statt das, was sie für richtig halten würden.

Ich finde das so bescheuert, dass man einen Fliesskommawert nicht darauf prüfen kann, ob es denn nun NaN ist. Wozu hat man dann NaN, wenn man es gar nicht prüfen kann?

Grüssli

knivil

Man kann es ueberpruefen. In <math.h> gibt es isnan. Mehr Infos unter: man isnan.

Dravere

knivil schrieb:

In <math.h> gibt es isnan.

Hmmm, ok, vielleicht ein wenig falsch ausgedrückt. Ich versuche es nochmals:
Wieso spezielle extra Funktionen einführen, statt einfach den Vergleich nehmen, welcher sowieso jede Sprache schon drin hat? Hat mir bisher nicht eingeleuchtet. Aber vielleicht kann mir das jemand erklären, wozu dies gut sein soll.

Grüssli

tempaccount_002

Christoph schrieb:

In der mathematischen Logik fordert man normalerweise sogar an grundlegendster Stelle, dass x == x immer wahr ist, egal was für einen Typ oder Wert x auch haben mag. NaN != NaN ist also sehr "unmathematisch", in gewisser Weise.

Genau. Der "==" - Operator ist für Fließkommazahlen nicht der mathematische Gleichheitsoperator. Das handelt man sich mit ungenauen Darstellungen eben ein.

otze

Christoph schrieb:

NaN != NaN ist also sehr "unmathematisch", in gewisser Weise.

Ja, aber sonst wär sowas möglich:

(0.0/0.0)==sqrt(-1) => true

Auch nicht wirklich Mathematisch.

Dravere schrieb:

knivil schrieb:

In <math.h> gibt es isnan.

Hmmm, ok, vielleicht ein wenig falsch ausgedrückt. Ich versuche es nochmals:
Wieso spezielle extra Funktionen einführen, statt einfach den Vergleich nehmen, welcher sowieso jede Sprache schon drin hat?

Du brauchst ja nicht isnan zu verwenden, einfache Logikoperatoren funzen auch.

Dravere

Tim schrieb:

Dravere schrieb:

knivil schrieb:

In <math.h> gibt es isnan.

Hmmm, ok, vielleicht ein wenig falsch ausgedrückt. Ich versuche es nochmals:
Wieso spezielle extra Funktionen einführen, statt einfach den Vergleich nehmen, welcher sowieso jede Sprache schon drin hat?

Du brauchst ja nicht isnan zu verwenden, einfache Logikoperatoren funzen auch.

Logikoperatoren?
1. Wie willst du das machen?
2. In welcher Sprache funktionieren Logikoperatoren auf Fliesskommazahlen? C# nicht, C++ nicht.

otze schrieb:

(0.0/0.0)==sqrt(-1) => true

Empfinde ich schon als mathematisch. Beides sind keine Zahlen. Ist doch korrekt?

Grüssli

Dravere schrieb:

Tim schrieb:

Dravere schrieb:

knivil schrieb:

In <math.h> gibt es isnan.

Hmmm, ok, vielleicht ein wenig falsch ausgedrückt. Ich versuche es nochmals:
Wieso spezielle extra Funktionen einführen, statt einfach den Vergleich nehmen, welcher sowieso jede Sprache schon drin hat?

Du brauchst ja nicht isnan zu verwenden, einfache Logikoperatoren funzen auch.

Logikoperatoren?
1. Wie willst du das machen?
2. In welcher Sprache funktionieren Logikoperatoren auf Fliesskommazahlen? C# nicht, C++ nicht.

Ich meinte natürlich die (Un-)gleichheitsoperatoren.

Christoph

otze schrieb:

Christoph schrieb:

NaN != NaN ist also sehr "unmathematisch", in gewisser Weise.

Ja, aber sonst wär sowas möglich:

(0.0/0.0)==sqrt(-1) => true

Auch nicht wirklich Mathematisch.

Ein Ausdruck wie (0.0/0.0)==sqrt(-1) ist in der Mathematik entweder nicht definiert oder hat einen willkürlichen Wahrheitswert (aber einen fest definierten). Mir ist bisher keine Präferenz auf false begegnet außerhalb von IEEE754.

Wenn man sich mit Logik beschäftigt, dann definiert man normalerweise zuerst, was "Variablen", "logische Operatoren", "Terme" etc. sind. Normalerweise nimmt man dabei == dazu und fordert, dass x == x gilt für alle x. Das passiert auf unterster Ebene, bevor es darum geht, was Variablen und Terme überhaupt darstellen sollen.

@tempaccount_002: Mir ist IEEE754 bekannt. Ändert nichts daran, dass ich NaN != NaN unmathematisch finde. Allerdings beschäftige ich mich zu wenig mit Numerik, um sagen zu können, ob NaN != NaN nützlicher ist als NaN == NaN oder nicht. Bei IEEE754 haben sich die Verantwortlichen mit Sicherheit viele Gedanken darüber gemacht, deswegen gehe ich davon aus, dass es gute Gründe für NaN != NaN gibt.

Fließkommazahlen würde ich übrigens nicht "ungenau" nennen. Alle darstellbaren Zahlen sind auch exakt darstellbar. Beispiel:

double a = 1.0;
double b = 2.0;
assert(b / 2.0 == a) // garantiert wahr, wenn nach IEEE754 gerechnet wird

Gerundet wird nur, wenn das exakte Ergebnis einer Operation nicht mehr darstellbar ist. Dadurch wird eine Ungenauigkeit eingeführt, aber eine deterministische und keine "wir wissen nicht was passiert"-Ungenauigkeit. Deswegen kann man sich auch streiten, ob man das "Ungenauigkeit" nennt.

SeppJ

Christoph schrieb:

Auto -> Farbe -> Rot
Auto -> Farbe -> Blau

Auto == Auto -> true
-> Rot == Blau ist true

Ne, so geht das nicht.
In der mathematischen Logik fordert man normalerweise sogar an grundlegendster Stelle, dass x == x immer wahr ist, egal was für einen Typ oder Wert x auch haben mag. NaN != NaN ist also sehr "unmathematisch", in gewisser Weise.

Du hast mich falsch verstanden (und viele andere auch). NaN bedeutet, dass das Ergebnis keine Zahl mehr ist. Die Behauptung dass alles was keine Zahl ist einander gleich ist, ist leicht zu widerlegen, was ich mit dem Auto-Telefon-Beispiel (etwas missverständlich) zeigen wollte.

Christoph

SeppJ schrieb:

Christoph schrieb:

Auto -> Farbe -> Rot
Auto -> Farbe -> Blau

Auto == Auto -> true
-> Rot == Blau ist true

Ne, so geht das nicht.
In der mathematischen Logik fordert man normalerweise sogar an grundlegendster Stelle, dass x == x immer wahr ist, egal was für einen Typ oder Wert x auch haben mag. NaN != NaN ist also sehr "unmathematisch", in gewisser Weise.

Du hast mich falsch verstanden (und viele andere auch). NaN bedeutet, dass das Ergebnis keine Zahl mehr ist. Die Behauptung dass alles was keine Zahl ist einander gleich ist, ist leicht zu widerlegen, was ich mit dem Auto-Telefon-Beispiel (etwas missverständlich) zeigen wollte.

Ich habe das in meinem Posting ein wenig umgekehrt betrachtet:
Die Behauptung, dass alles, was unterschiedliche Farben hat, ungleich ist, ist leicht zu widerlegen, was ich mit dem Auto-Auto-Beispiel zeigen wollte.

Bei dir scheint NaN_1 != NaN_2 zu sein, weil NaN_1 einen anderen Typ (Auto) hat als NaN_2 (Telefon). Wenn man aber auf Gleichheit testen möchte, muss links und rechts den gleichen Typ stehen, sonst ist der Ausdruck weder true noch false, wie knivil weiter vorne geschrieben hat. Wenn man dein Auto-NaN und Telefon-NaN auf ein allgemeines NaN castet, geht die Auto/Telefon-Information verloren, und damit wäre NaN == NaN einsehbar.

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum Neuigkeiten aus der realen Welt in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

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 :).