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).
Kommentare (14)