ChrisB: Chekbox

Beitrag lesen

Hi,

Dein Beispiel erklärt, warum NaN bei anderen (arithmetischen) Operatoren zerstörerisch wirkt. Die Regel, dass der Vergleichsoperator beim Vergleich mit NaN immer false zurückgibt, hilft aber nur wenig weiter. Sie hilft nur in dem Fall, dass *beide* Operatoren unabhängig voneinander ungültig (NaN) werden *und* man vermutet, dass sie gleich sind.

Ja, eben.

Nimm an, du berechnest "5 mal Elephant" und "Krokodil minus 13" - ohne beabsichtigt zu haben, dass deine Berechnungen mit derart unsinnigen Werten arbeiten - und möchtest vom Vergleich des Ergebnisses dieser beiden Berechnungen abhängig machen, ob dein Script etwas bestimmtes tut.
Das *soll* es natürlich nur, wenn die eine Berechnung bspw. 3*4 und die andere 6*2 war, also 12==12, OK, gebe die Codes für die Atomrakten heraus.
Wenn NaN==NaN wäre, dann würde das Script das auch tun, wenn es nur mit reichlich unsinnigen Eingabedaten gefüttert würde - obwohl dieses Verhalten nicht im geringsten beabsichtigt wäre.
Klar, das Beispiel ist an den Haaren herbeigezogen, und klar, man *könnte* vorher beide Ergebnisse erst mal auf Plausibilität prüfen, ob sie also wenigstens nicht NaN sind - aber daran denkt der Scriptersteller ja vielleicht nicht immer.
Und deshalb sehe diese Definition für das Verhalten des Vergleiches von NaN als eine beabsichtigte Vorsichtsmaßnahme, ähnlich wie beim bereits erwähnten Verhalten von NULL in SQL, wo NULL ja idR. auch für einen ausserordentlichen, "nicht normalen" Wert steht.

MfG ChrisB

--
Light travels faster than sound - that's why most people appear bright until you hear them speak.