Frage zu Fließkommadarstellung in Java

[samhain]

Hallo Zusammen,

ich bin gerade am durcharbeiten meines Java Buchs und bin dabei auf folgende Aufgabe gestoßen:

Frage Was ist das Ergebnis der Ausgabe?
1.

System.out.println(20000000000F == 20000000000F+[B]1[/B]); // Ausgabe: true

2.

System.out.println(20000000000D == 20000000000D+[B]1[/B]); // Ausgabe: false

Erstmal war ich verdutzt, weil ich beide als false angenommen hatte. Eine kurze Suche bei google ergab dann etwas mit interner Darstellung Mantisse Exp usw. und da fiel mir auch ein das da mal was war...^^. Jetzt wollte ich das aber doch nochmal um es mir zu verdeutlichen einfach nachrechnen und da kommt auch meine erste Frage...

Die 20.000.000.000 + 1 binär dargestellt: 10010.10100.00001.01111.10010.00000.00001 (35 Stellen)

Nun hat die Single Precision Darstellung ja nur 32 Stellen -> 3 Stellen fallen schonmal weg:
10010.10100.00001.01111.10010.00000.00[001]

Durch das VZ-Bit und den Exponenten gehen ja nochmal 9 Bit der eigentlichen Zahl verloren:
10010.10100.00001.01111.100{10.00000.00}[001]

Die Mantisse müsste dann das sein: 10010.10100.00001.01111.100 sprich auch der Wert, der auf Gleichheit geprüft wird. Das mit der 1 ist mir auch soweit klar...Jetzt habe noch geschaut, wann der Wert sich ändert also von true auf false gesetzt wird.
Das passiert bei 1024 (binär: 10000000000)
Die Mantisse müsste dann also so aussehen: 10010.10100.00001.01111.101

Ich muss die 1024 doch nur zur ursprünglichen Zahl addieren, was bei mir so aussieht:
10010.10100.00001.01111.10010.00000.00001 + 10000000000 = 10010.10100.00001.01111.10011.00000.00001 <--- und das hier verstehe ich nicht!? Demnach wäre die Ausgabe immer noch true :bahnhof:


Frage 2 und 3 mach ich kurz:

Der Wertebereich von Float wird bei 4 Byte mit + 3,402...E+38f angegeben. Dies übersteigt das Beispiel von oben aber bei weitem. Wenn das Beispiel von oben aber schon nicht richtig darstellbar ist unter Float wieso hat man dann diesen Bereich? Bzw. wenn das Problem wegen dem 32 Bit System ist wieso geht es bei Double?

Vielleicht liegts auch grad einfach nur an der Uhrzeit, ich geh jetzt erstmal pennen.

Gruß Sam

 

[Volvagia]

Liegt das nicht einfach an der Ungenauigkeit von Gleitkommazahlen, dass bei so großen Zahlen der selbe Wert da gestellt wird? Und double sind eben doppelt so genau.

 

[Ark]

double und float belegen 64 bzw. 32 Bit an Speicher. Allerdings werden davon nur bis zu 52 bzw. 23 Bit davon benutzt, um die Ziffernfolge binär zu speichern. (Hinzu kommt in diesem Fall noch jeweils ein "hidden bit", aber das ist hier ohne Belang.)

Rechne dir doch mal den Zweierlogarithmus von 20000000001 aus: 34,219… D.h., um diese Zahl im Binärsystem zu speichern, braucht man mehr Bits, als float dafür zur Verfügung stehen. double hat hier aber eine genügend hohe Genauigkeit.

Ark

 

[samhain]

@Volvagia: So wie ich das verstanden habe bezieht sich die Ungenauigkeit darauf, dass die im Rechner darstellbaren Zahlen eine kleine Teilmenge der reellen Zahlen sind und nicht alle Werte dargestellt werden können bzw. nur bedingt genau dargestellt werden können, wie PI zum Beispiel. Die 20 Milliarden von oben sind aber gut darstellbar.

double und float belegen 64 bzw. 32 Bit an Speicher. Allerdings werden davon nur bis zu 52 bzw. 23 Bit davon benutzt, um die Ziffernfolge binär zu speichern. (Hinzu kommt in diesem Fall noch jeweils ein "hidden bit", aber das ist hier ohne Belang.)

Das war wohl von Belang ...in meiner obigen Rechnung habe ich das Hidden Bit vergessen, jetzt stimmt auch endlich mein Ergebnis.

Irgendwie war ich bisher immer der Meinung single precision bei 32 Bit Systemen und double precision bei 64 Bit Systemen. Jetzt hab ich es aber kapiert, dass es nicht vom System abhängt.

Damit sind meine Fragen geklärt bis auf: Wieso hat Float dann diesen großen Wertebereich, wenn es gar nicht dargestellt werden kann? Dann kann ich von Haus aus immer gleich Double nehmen...

 

[nillehammer]

Dann kann ich von Haus aus immer gleich Double nehmen...

Wenn es auf große Genauigkeit ankommt ist auch Double nix. Gewöhn Dich lieber daran, immer BigDecimal zu benutzen.