Aus Softwarefehlern lernen – Teil 8: Rundungs- und Gleitkommafehler

Zahlen erscheinen in der Programmierung oft eindeutig und exakt – zumindest, solange man sich in ganzzahligen Bereichen bewegt. Doch sobald Gleitkommazahlen, Dezimalwerte oder Rundungen ins Spiel kommen, entstehen subtile Probleme. Kleine Ungenauigkeiten, die im ersten Moment harmlos wirken, können sich mit der Zeit summieren und massive Auswirkungen haben.

Muster 8: Rundung, Trunkierung und kumulative Fehler: Wenn kleine Abweichungen groß werden

Ein lehrreiches Beispiel stammt aus der Finanzwelt, nämlich dem Vancouver Stock Exchange (VSE) in den frühen 80er-Jahren. Der Börsenindex der VSE startete ursprünglich bei 1.000 Punkten. Nach fast zwei Jahren notierte er scheinbar bei rund 524 Punkten – was wie ein dramatischer Markteinbruch aussah. Tatsächlich hatte sich der Markt jedoch kaum verändert. Die Ursache war banal und gleichzeitig folgenschwer: Es handelte sich um Rundungs- und Trunkierungsfehler.

Nach jeder Transaktion wurde der Index nämlich auf drei Dezimalstellen getrimmt – und zwar durch Abschneiden (Trunkierung), nicht durch korrektes Runden. Dieser winzige Verlust setzte sich bei tausenden Updates pro Tag fort. Die kumulativen Fehler führten nach und nach zu einer schleichenden Absenkung des Index, bis er fast halbiert war. Erst nach einer umfassenden Korrektur sprang er schlagartig wieder auf rund 1.098 Punkte hoch.

Dieses Muster findet sich nicht nur im Finanzbereich. Jede Software, die periodisch Berechnungen durchführt, Zwischenergebnisse speichert oder fortlaufend Rundungen vornimmt, kann in die gleiche Falle tappen. Typische Beispiele:

• Zinsberechnungen und Zahlungspläne: Falsch gerundete Centbeträge, die sich über Monate auf Hunderttausende summieren.
• Statistiken und Berichte: Prozentwerte, die bei jeder Aggregation minimal nach unten oder oben verzerrt werden.
• Physik- und Simulationstools: Kleine Ungenauigkeiten in Gleitkommawerten, die über tausende Iterationen davonlaufen.
• Spiele und Echtzeitanimationen: Ein ständiger minimaler Fehler in der Position kann nach Minuten oder Stunden sichtbar werden.

Das Perfide an dieser Fehlerklasse ist, dass die ersten Ergebnisse durchaus plausibel aussehen. Eine Zahl wie 99,999 statt 100,0 fällt nicht notwendigerweise auf – bis sie tausendfach akkumuliert ist. Kumulative Rundungsfehler können dabei auf verschiedene Weise Schaden anrichten:

1. Falsche Geschäftsentscheidungen: Ein Unternehmen könnte fälschlicherweise glauben, dass ein Portfolio Wert verliert oder eine bestimmte Handelsstrategie unprofitabel ist.
2. Fehlerhafte Auswertungen und Alarmierungen: Monitoring-Systeme, die Schwellenwerte überwachen, können falsche Warnungen auslösen oder echte Probleme übersehen.
3. Rechtliche und steuerliche Probleme: Schon minimale Differenzen in Geldbeträgen können zu Compliance-Verstößen oder Kundenbeschwerden führen.

Tatsächlich ist es sehr einfach, passende Gegenmaßnahmen für stabile Zahlen zu ergreifen – wie so oft muss diese nur auch jemand umsetzen:

1. Dezimalarithmetik verwenden: Für Geld und präzise Berechnungen niemals Binär-Gleitkommazahlen (wie float oder double) nutzen, sondern dezimale Typen wie decimal in C#, BigDecimal in Java oder Bibliotheken wie decimal.js in JavaScript.
2. Rundungsstrategie explizit festlegen: Ob Banker’s Rounding, mathematisches Runden oder Trunkierung – die Regel muss dokumentiert und einheitlich umgesetzt sein.
3. Rekalkulationen from scratch: Wenn die Notwendigkeit besteht, Daten zu aggregieren oder fortzuschreiben, sollte das System regelmäßig aus den Rohdaten neu berechnen, um Drifts zu erkennen und zu korrigieren.
4. Property-Based Testing und Langzeitsimulationen: Tests, die viele Iterationen simulieren, decken schleichende Effekte auf, bevor sie produktiv Schaden anrichten.

Viele Entwicklerinnen und Entwickler neigen dazu, Rundungsfragen als Detail zu betrachten. Es wirkt harmlos – bis es reale Folgen hat. Das Beispiel der Vancouver Stock Exchange zeigt, dass ein halber Punkt Verlust pro Transaktion in der Summe Milliarden an Marktverschiebung auslösen kann.

Wer präzise arbeitet, behandelt Zahlen nicht als bloße Technikfrage, sondern als Teil des Domänenmodells. Geldbeträge, Sensorwerte oder wissenschaftliche Messungen haben oft klare Regeln, wie sie zu runden oder darzustellen sind – und genau diesen Regeln muss auch die Software folgen.

(who)