So, hier endlich die Fortsetzung zum Thema “Rechnen mit Gleitkommazahlen”. Das letzte mal habe ich erklärt, was Gleitkommazahlen überhaupt sind und wie sie im Computer dargestellt werden. Den Nachteil dieser Zahlendarstellung habe ich auch schon vorgestellt: es lassen sich nicht sämtliche Zahlen in einem bestimmten Bereich darstellen (was bei den reellen Zahlen ohnehin mit endlichem Speicher nicht möglich wäre); schlimmer noch ist aber, dass die Abstände zwischen den darstellbaren Zahlen immer größer werden, je größer die Zahlen selber werden. Tückisch wird das vor allem dann, wenn es ans Rechnen mit Gleitkommazahlen geht. Und das soll das heutige Thema sein.

Bevor die Probleme beim Rechnen dargelegt werden können, muss natürlich erst einmal geklärt werden, wie mit Gleitkommazahlen überhaupt gerechnet wird. Glücklicherweise ist das nicht allzu umständlich und lässt sich relativ schnell erklären. Insbesondere Multiplikation und Division lassen sich (in der Theorie) sehr einfach umsetzen; bei der Multiplikation werden einfach die beiden Mantissen (welche ja Festkommazahlen darstellen) miteinander multipliziert und die beiden Exponenten addiert. Wollen wir zum Beispiel die beiden Dezimal-Zahlen 2.5*105 und 6.1*103 miteinander multiplizieren, so rechnen wir:

2.5 * 6.1 = 15.25

und

5 + 3 = 8

Damit erhalten wir als Ergebnis 15.25*108, was in der Tat der gewünschten Zahl entspricht. Bei der Division kann man genauso vorgehen, nur dividiert man hier die Mantissen und subtrahiert die Exponenten. Im dualen Zahlensystem funktioniert die Rechnung genauso, kann also auch auf den Bitketten der bereits vorgestellten Gleitkommadarstellung im Computer durchgeführt werden – ich führe die weiteren Rechnung aber alle im Dezimalsystem aus, damit sie besser verständlich sind.

Für Addition und Subtraktion muss nur ein zusätzlicher Schritt durchgeführt werden: vor der eigentlichen Rechnung müssen die Exponenten angeglichen werden. Sollen also etwa die beiden oben genannten Zahlen 2.5*105 und 6.1*103 addiert werden, so muss die erste Zahl entweder als 250.0*103 oder die zweite als 0.061*105 umgeschrieben werden – üblicherweise transformiert man die kleinere Zahl hin zum größeren Exponenten. Anschließend reicht es, die beiden Mantissen zu addieren. Für obiges Beispiel ergibt sich damit die folgende Rechnung:

2.5*105 + 6.1*103 = 2.5*105 + 0.061*105 = 2.561*105

So weit, so einfach. Die Anpassung des Exponenten kann übrigens ziemlich einfach durchgeführt werden, indem das Komma der Mantisse um die benötigte Anzahl an Stellen nach links oder rechts geschoben wird (das geht im dualen wie im dezimalen System gleichermaßen).

Die Problematik entsteht dadurch, dass im Computer nur eine bestimmte Menge an Bits für eine Gleitkommazahl zur Verfügung stehen; insbesondere die beschränkte Mantissenlänge (für Gleitkommazahlen einfacher Genauigkeit sind das etwa 23 Bit) erweist sich hier als der größte Fallstrick mit verschiedenen Auswirkungen.

Eine dieser Auswirkungen ist die sogenannte Auslöschung (im Englischen cancellation genannt). Sie tritt auf, wenn bei der Verrechnung ähnlicher Zahlen niederwertige Informationen verloren gehen und sich dabei zwar nicht der absolute Fehler, dafür aber der relative Fehler erhöht. Als absoluten Fehler bezeichnet man die tatsächliche Abweichung einer (berechneten) Zahl vom eigentlich gewünschten Wert. Soll etwa das Ergebnis einer Rechnung den Wert 0.51 ergeben, der Computer errechnet aber stattdessen 0.50, so haben wir einen absoluten Fehler von 0.01. Berechnen wir 100.50, wollten aber 100.51, so ist der absolute Fehler ebenfalls 0.01. Der relative Fehler bezeichnet dementsprechend die relative Abweichung der beiden Werte (des berechneten und des eigentlich korrekten) voneinander. Beim Wertepaar 100.51/100.50 beträgt der relative Fehler (die relative Abweichung) knapp 0.01%, wohingegen es beim Wertepaar 0.51/0.50 bereits 2% Abweichung sind. Der Effekt tritt insbesondere bei der Subtraktion auf; ein Beispiel: angenommen, wir haben die Zahlen 1.2345*105 und 1.2340*105 und wollen sie voneinander subtrahieren. In der “gewöhnlichen” Mathematik ist das kein Problem und wir erhalten als Ergebnis: 

  1.2345*105
– 1.2340*105
____________
= 0.0005*105

Rechnen wir nun aber am Computer, so ist ja die maximale Anzahl an speicherbaren Ziffern in einer Zahl beschränkt; stehen uns zum Beispiel nur 4 Ziffern zur Verfügung (im binären System würde das 4 Bit entsprechen), so würden statt der originalen Zahlen gerundete verwendet werden. Wir hätten also die folgende Rechnung:

1 / 2 / 3 / Auf einer Seite lesen

Kommentare (14)

  1. #1 rolak
    September 15, 2011

    Imho macht jeder Programmierer irgendwann die erhellende Erfahrung, daß es eben nicht egal ist, was in welcher Reihenfolge gerechnet wird. Ganz besonders bei Algorithmen, die in winzigsten Schritten von einem Wert zum nächsten hüpfen – bei mir wars vor langen Jahren ein Programm, das die Lösung mittels ballistischer numerischer Integration zu finden suchte. Und bei der Wahl der Randbedingungen für den nächsten Versuch eigentlich nur im Nebel stocherte, da die erste Runge-Kutta-Implementierung die Besonderheiten des Modells eben nicht berücksichtigte.

  2. #2 Engywuck
    September 15, 2011

    exzellenter Artikel, vielen Dank.

    Als Ergänzung zu deinen Ausführungen sei noch ein komplexeres Beispiel erwähnt: die Berechnung der Nullstellen einer quadratischen Funktion.
    Mathematisch liegen diese ja bei x1/2 = ( -b +/- wurzel(b^2-4ac) ) / 2a
    Durch das Quadrat wird b innerhalb der Klammer aber gerne mal zu klein oder groß, wodurch Genauigkeitsverluste entstehen (bzw. im Extremfall die Wurzel imaginär wird). Viel gravierender ist aber der nicht unübliche Fall, dass a, b und c in ähnlicher Größenordnung liegen. Dann kann es passieren, dass b^2 gegenüber 4ac genügend groß wird, dass die Auslöschung greift und wurzel(b^2-4ac) ungefähr b wird. Hups 😀
    Mit einer abgewandelten – komplexeren – Formel lässt sich das aber in den Griff bekommen.

    Ein berühmter Programmierfehler ist auch, mit Gleitkomma zu rechnen (ggf. implizit bei automatischer Typkonvertierung, z.B. weil ein Zwischenergebnis nicht mehr in ein double passt) und dann auf Gleichheit zu testen. Hat auch mir schon manche Stunde Freude gemacht….

    Der Vollständigkeit halber (wer sich die blutigen Details gönnen will…) sei http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html erwähnt.

  3. #3 Engywuck
    September 15, 2011

    noch was: wenn man sich endlich an Rundungsfehler gewöhnt hat kann einem auch das hier passieren….
    http://www.xkcd.com/217/

  4. #4 berti
    September 17, 2011

    mal was anderes, ich lese dich nämlich echt gerne, aber was nervt ist das der rss feed nicht funzt. kthxbye

  5. #5 Marcus Frenkel
    September 17, 2011

    @berti
    Das liegt dann aber nicht an mir…;)
    Mein RSS-Feed geht für ganz SB.de, inklusive meines Blogges. Vielleicht einmal die Einstellungen überprüfen?

  6. #6 rolak
    September 17, 2011

    Keine Ahnung welchen er meint, doch die beiden sind unterschiedlich: Im globalen thread-feed tauchen Deine posts auf, aber im globalen comment-feed nicht die dazu gehörenden Kommentare (lokale feeds nutze ich nicht).

    So bleibt nur zu-Fuß-abonnieren mit einem Kommentar/Artikel. Und selbst das muß ich bei Interesse manchmal ein zweites Mal unternehmen, was dann allerdings nicht mit der ‘üblichen’ nick-mail-combi funktioniert. Zum Abschluß die gute Nachricht: Dreimal war noch nie nötig 😉

    btw: Eben beim Nachschauen stellte ich fest, daß dies blog zwar im Blog-Index, nicht aber in der rss-Liste der blogs auftaucht. Vielleicht ist dieser Lapsus dafür verantwortlich oder läßt zumindest auf eine gemeinsame Ursache schließen…

  7. #7 Marcus Frenkel
    September 17, 2011

    Hmmm…da muss ich die zuständige Person dafür mal nerven. Danke für den Hinweis.

  8. #8 rolak
    September 17, 2011

    ooops, etwas Wichtiges zur Präzisierung fehlt: Der Bedarf an ‘Nachabonnieren’ besteht blogunabhängig auf ganz SB.de, nicht etwa ausschließlich bei Bits&Bytes. Obgleich, eine Strichliste habe ich nicht geführt…

  9. #9 Knorre
    Oktober 24, 2013

    Hallo Zusammen. Hab mal eine Frage. Vielleicht kann mir ja hier jemand helfen? Bei einer Excel Pivot Tabelle kommen 4 werte zustande welche 4 nachkommastellen aufweisen, und 12 mal null (nicht NULL) werte. Wenn man diese Werte miteinander summiert sollten sich die 4 werte aufheben und zusammen null ergeben. Allerdings komme ich sowohl wenn ich die werte markiere, als auch wenn ich mit vba rechne auf -0,00000000000000000045623…
    ich habe bei jeder einzlnen zahl alle 30 möglichnen nachkommastellen eingeblendet, da sind abe einfach keine werte zu finden. Bin etwas ratlos, würde aber wirklich gerne wissen wie es zu sowas kommen kann, Ich hätte auch screenshots und die werte als excel file, falls jemand interesse hat.
    danke. vIelmals

  10. #10 Marcus Frenkel
    Oktober 24, 2013

    @Knorre
    Da wird wohl vermutlich der hier genannte Effekt eintreten: bei der Summierung der Zahlen kommt es zu kleinen Rechenungenauigkeiten, in deren Folge ein kleiner Restwert ungleich 0 übrig bleibt. Was passiert denn, wenn die Reihenfolge der 4 Werte in der Summierung geändert wird – ändert das etwas am Ergebnis?

    In welchen Größenbereichen sind die 4 Zahlen?

  11. #11 rolak
    Oktober 25, 2013

    Die in Knorres Rest vorhanden 4e-19 entsprechen einem Bit in der 65.ten Stelle. Es reichen für solche Effekte ein paar vorzeichen-verschiedene <1e30-Werte (sein Nachkommastellen-Test) wohl aus, falls die Nullen Rechenergebnisse sind, sollte der Grund klar sein.
    Sonst könnte ja auch spaßeshalber die Binär-Rechnung ‘zu Fuß’ nachvollzogen werden…

  12. #12 rolak
    Oktober 25, 2013

    püh, noch kein breites Grinsen weit und breit: Da waren heute morgen wohl noch gewisse Gegenden des Brägens im Tiefschlaf… 1e-19 wäre die 63. Stelle, mithin 4e-19 die 61. Plus und Minus, oha^^

  13. #13 Markus
    Januar 15, 2015

    Besten Dank an den Author, ein absolut überragender Artikel, wirklich klasse!!

    Bisher ohne Plan von Fließkommazahlen, einmal durch gelesen, alles gecheckt, Informatik Klausur kann kommen!

  14. #14 Marcus Frenkel
    Januar 15, 2015

    Danke und viel Erfolg. 🙂