0.0 == -0.0?
-
0 ist weder + noch -. von daher kann der Vergleich nicht stattfinden, und -0 gibt es nicht, genauso wie es +0 nicht gibt.
-
Wenn Du in Fließkommadarstellung die Mantisse auf 0.0 setzt, aber das Vorzeichenbit auf negativ packst, gibt es auch -0.0.
-
phlox81 schrieb:
0 ist weder + noch -. von daher kann der Vergleich nicht stattfinden, und -0 gibt es nicht, genauso wie es +0 nicht gibt.
Das hast du aber ziemlich willkürlich definiert :p
Wenn ich in einem Körper -x als additiv Inverses von x definiere (wie es üblich ist), dann gibt es 0 und -0, sie sind nur zufällig dasselbe.
-
Man sollte die Ausgangsfrage vielleicht auf IEEE Gleitkommazahlen einschränken.
Eine lustige verwandte Frage. Gegeben folgender Code:
union Foo{ float f; int i; }; //... union Foo a, b; a.f = 0.0; b.f = -0.0;Was ist der Wert von a.f == b.f und von a.i == b.i ?
-
undefined behaviour
-
-0.0 = -1*0.0 = 0.0
=> 0.0 == -0.0
-
true auch wenn sich das Bitmuster unterscheidet. FP Vergleiche sind ja nicht einfach Bitmuster vergleiche (zB ist NaN == NaN false, obwohl es das gleiche Bitmuster ist (ups hab nicht gesehen, dass es auch einen NaN == NaN Thread gibt :)))
-
rüdiger schrieb:
(zB ist NaN == NaN false, obwohl es das gleiche Bitmuster ist ))
Nein, es gibt unterschiedliche NaNs. Bei IEEE-754-32Bit-Gleitkommazahlen sogar 2^23 Stück. NaNs enthalten so zu sagen noch einen Fehlercode.
EDIT: Dreher im Exponent verbessert
-
Da bleibt aber nicht viel für die eigentlichen Nutzdaten
-
knivil schrieb:
Bitte markiere exakt den Wert 0.0 auf der Zahlengeraden. Bitte markiere exakt den Wert -0.0 auf der Zahlengeraden. Liegen die beiden Markierungen exakt uebereinander? ... ups, das war ja schon ein Test. Hey, aber was ist, wenn 0.0 eine Zeichenkette (Wort) ist, genau wie -0.0? Dann sind sie ja nicht gleich.
Daraus folgt: bescheuerte Frage!
Dieser Thread und der Thread über "NaN == NaN?" beziehen sich auf die Darstellung der Fließkommazahlen auf Bit-Ebene. Auf Bit-Ebene werden 0.0 und -0.0 eben unterschiedlich dargestellt. Trotzdem gelten sie als gleich. Bei NaN ist es andersherum. Dort kann ein "a==a" false ergeben.
Das ist ein Verhalten von Fließkommazahlvergleichen, das ich nicht unbedingt intuitiv finde. Deshalb interessiert mich in dem Zusammenhang die Meinung der anderen Forenteilnehmer.
"Wie sollte es eurer Meinung nach sein?"
"Ist dieses Verhalten überhaupt allen bekannt?" (Ich muss sagen, dass ich letzt etwas von NaN != NaN überrascht wurde.)Das sind Fragen, die sich mir da stellen.
-
Gregor schrieb:
Das ist ein Verhalten von Fließkommazahlvergleichen, das ich nicht unbedingt intuitiv finde. Deshalb interessiert mich in dem Zusammenhang die Meinung der anderen Forenteilnehmer.
Ist für mich total intuitiv.
pow(sqrt(-4),2) ergibt nan
pow(sqrt(-9),2) ergibt nan
würde jetzt nan==nan gelten, würde ich gleich denken, daß -4==-9, was nicht unbedingt der Fall ist.
-
volkard schrieb:
Gregor schrieb:
Das ist ein Verhalten von Fließkommazahlvergleichen, das ich nicht unbedingt intuitiv finde. Deshalb interessiert mich in dem Zusammenhang die Meinung der anderen Forenteilnehmer.
Ist für mich total intuitiv.
pow(sqrt(-4),2) ergibt nan
pow(sqrt(-9),2) ergibt nan
würde jetzt nan==nan gelten, würde ich gleich denken, daß -4==-9, was nicht unbedingt der Fall ist.false ist nicht das gleiche wie "ist nicht unbedingt der Fall". Bei
a=sqrt(-1)
a==a?ist das Verhalten IMHO nicht sehr intuitiv.
Hmmm... vielleicht bräuchte man da eine dreiwertige Logik.
-
Gregor schrieb:
Hmmm... vielleicht bräuchte man da eine dreiwertige Logik.
Ja.
Aber andererseits sind wir aus dem Mathematikunterricht der Schule schon gewohnt, daß in ähnlicher Weise vorgegangen wird.
2/0==2/0 ?
4/0==9/0 ?
-
volkard schrieb:
Gregor schrieb:
Hmmm... vielleicht bräuchte man da eine dreiwertige Logik.
Ja.
Aber andererseits sind wir aus dem Mathematikunterricht der Schule schon gewohnt, daß in ähnlicher Weise vorgegangen wird.
2/0==2/0 ?
4/0==9/0 ?Gilt eigentlich "Infinity == Infinity" nach IEEE?
-
Gregor schrieb:
Gilt eigentlich "Infinity == Infinity" nach IEEE?
Hoffentlich nicht!
Sonst hätte man ja dauernd 10*x==9*x, ohne daß x==0.
-
volkard schrieb:
Gregor schrieb:
Gilt eigentlich "Infinity == Infinity" nach IEEE?
Hoffentlich nicht!
Sonst hätte man ja dauernd 10*x==9*x, ohne daß x==0.Gilt aber. Ich habe gerade mal gesucht und das da gefunden:
http://compilers.iecc.com/comparch/article/98-07-134
Erik Runeson wrote:
> When comparing floating-point numbers, should infinity (Inf) be
> concidered equal to infinity?> Inf == Inf ?
The IEEE 754 standard for floating-point arithmetics does not say
anything about this case, but a similar case is:The IEEE 754 standard does implicitly define Infinity == Infinity to
be true. The relevant part of the standard is section 5.7: "Four
mutually exclusive relations are possible [between two IEEE 754
values]: less than, equal, greater than, and unordered. The last case
arises when at least one operand is NaN." Between any pair of
floating point values exactly one of these four relations is true.
Therefore, since Infinity is not NaN, Infinity is not unordered with
respect to itself. Having one of (Infinity < Infinity) and (Infinity
> Infinity) be true wouldn't be consistent, so (Infinity == Infinity).
-
volkard schrieb:
Ist für mich total intuitiv...
Na ja... ich sehe im NaN intuitiv einen Zustand - "not a number" Zustand. Daher, intuitiv, NaN == NaN, true.
Und 0.0 == -0.0 kann man ja ohne Probleme berechnen. Daher auch true.
-
abc.w schrieb:
volkard schrieb:
Ist für mich total intuitiv...
Na ja... ich sehe im NaN intuitiv einen Zustand - "not a number" Zustand. Daher, intuitiv, NaN == NaN, true.
Ich sehe darin einen Rechenfehler.
Daher intuitiv, ein Rechenfehler ist normalerweise nicht gleich dem anderen Rechenfehler.
-
für mich isses false weil das - extra reserviert werden muss
-
Für mich ist es true, denn für mich ist 0.0 das gleiche wie -0.0. Zumindest bei der Programmierung, bei der eigentlichen Mathematik könnte man sich wohl nochmal darum streiten.