1.235*105
– 1.234*105
___________
= 0.001*105

Man sieht, dass der absolute Fehler bei der ersten (gerundeten) Ausgangszahl und dem (demzufolge inkorrekt berechneten) Ergebnis jeweils gleich ist, nämlich
0.0005*105. Der relative Fehler jedoch ändert sich dramatisch, von lächerlichen 0.04% (1.2345 zu 1.235) auf gewaltige 50% (0.0005 zu 0.001)! Man kann sich einfach vorstellen, dass derartige Abweichungen schnell zu vollkommen falschen Ergebnissen führen können, wenn nämlich mehrere Berechnungen nacheinander ausgeführt werden, wobei die (Zwischen-)Ergebnisse vorhergehender Rechnungen als Werte in die nächste Rechnung mit eingehen.

Doch damit nicht genug: auch bei der Verrechnung von Zahlen sehr unterschiedlicher Größe kann es zu einem Fehler kommen, der sogenannten Absorption. Sie hat die gleiche Ursache wie die Auslöschung, nämlich die beschränkte Anzahl an Mantissenstellen. Zur Absorption kann es kommen, wenn der Exponent einer sehr kleinen Zahl an den einer sehr großen Zahl angepasst wird und dabei viele oder sämtliche signifikanten Mantissenziffern verloren gehen. Auch hierfür ein kurzes Beispiel: nehmen wir die Zahlen 1.0*105 und 1.5*102, welche wir addieren wollen (wobei wir weiterhin 4 Ziffern für die Mantisse speichern können). Für die Addition muss der Exponent der zweiten Zahl angepasst werden; man würde sie also folgendermaßen umschreiben:

1.5*102 = 0.0015*105

Da wir aber nur 4 Ziffern speichern können, ergibt sich stattdessen die Zahl
0.001*105. Führen wir nun die Addition aus, ergibt sich statt der korrekten Rechnung

  1.0000*105
+ 0.0015*105
___________
= 1.0015*105

die nicht akkurate Rechnung

  1.000*105
+ 0.001*105
___________
= 1.001*105

Durch die Rundung haben wir also ein inkorrektes Ergebnis erhalten. Dies kann sogar so weit führen, dass bei hinreichend großem Unterschied in den Exponenten die zweite Zahl überhaupt keinen Beitrag mehr zur Rechnung hat, wenn nämlich sämtliche Signifikanten Ziffern bei der Anpassung des Exponenten verloren gehen. Glücklicherweise tritt dieses Problem nur bei der Addition und Subtraktion auf, da bei Multiplikation und Division keine Anpassung des Exponenten und damit kein Verlust von Mantissenziffern stattfindet.

Zusätzlich können die Auswirkungen dieses Effekts durch geschicktes Rechnen vermindert werden. Angenommen, zu einer sehr großen Zahl sollen viele sehr kleine Zahlen addiert werden. Führt man die Rechnung in der üblichen Art und Weise durch (indem man die ganzen kleinen Zahlen auf die große addiert), erhält man am Ende unter Umständen ein falsches Ergebnis, da sämtliche Ziffern der kleinen Zahlen bei der Addition verloren gegangen sind. Addiert man dagegen zuerst die kleinen Zahlen miteinander und verrechnet dieses Ergebnis erst mit der großen Zahl, kann man das Glück haben, dass die Addition der kleinen Zahlen ein genügend großes Ergebnis ergibt, dass es bei der Addition mit der großen Zahl noch einen Einfluss auf die Rechnung hat.

Die beiden vorgestellten Effekte ziehen noch einen weiteren nach sich, nämlich, dass das aus der Mathematik bekannte Assoziativ– und das Distributivgesetz im Bereich der Gleitkommazahlen am Computer nicht mehr gelten. Wir erinnern uns: das Assoziativgesetz sagt aus, dass (a+b)+c = a+(b+c) gelten soll (auf deutsch, dass es egal ist, welche Bestandteile einer Summe zuerst miteinander addiert werden). Gerade eben haben wir aber gesehen, dass gerade das aber bei Gleitkommazahlen nicht gilt, da es durchaus relevant ist, ob man zuerst Zahlen gleicher Größenordnung oder zuerst Zahlen unterschiedlicher Größenordnung miteinander verrechnet. Das Distributivgesetz besagt, dass a*(b+c) = (a*b)+(a*c) gelten soll, was auf Grund der eben genannten Problematik bei Gleitkommazahlen leider auch nicht uneingeschränkt gilt.

All die genannten Probleme zeigen, dass das Rechnen mit Gleitkommazahlen am Computer nicht ganz einfach ist. Insbesondere in Bereichen mit vielen Berechnungen müssen sich die Programmierer einer Anwendung daher genaue Gedanken darüber machen, wie und in welcher Reihenfolge sie ihre Berechnungen durchführen. Allein die Änderung der Berechnungsreihenfolge kann da schon zu erheblichen Verbesserungen führen; manchmal sind aber auch neue oder abgewandelte Formeln notwendig, um die gröbsten Probleme bei der Berechnung zu umgehen. In Umgebungen, wo allerhöchste Präzision gefragt ist, ist das natürlich keine Lösung; hier würde der Programmierer dann auf andere Methoden der Zahlendarstellung zurückgreifen (die so viele Bits für eine Zahl zur Verfügung stellen, wie benötigt werden – die aber auch nicht mehr einfach so von der CPU verarbeitet werden können).

1 / 2 / 3

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 https://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….
    https://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. 🙂