Warum 0.1 + 0.2 Nicht 0.3 Ergibt: Gleitkommazahlen Erklärt

Führen Sie 0.1 + 0.2 in einer Python-Shell aus, kommt nicht 0.3 heraus, sondern 0.30000000000000004. Probieren Sie es in JavaScript, Java, Go, C oder Rust, und Sie bekommen denselben sechzehnstelligen Schwanz. Jede dieser Sprachen tut genau das, was der Hardware-Standard vorschreibt. Eine Zahl, die unendlich viele Binärstellen bräuchte, wird in 64 Bit gepresst, und irgendetwas muss nachgeben.

Warum sich 0.1 nicht exakt binär speichern lässt

Computer speichern Gleitkommazahlen zur Basis 2. In Basis 2 hat der Bruch 1/10 eine periodische Entwicklung, genau wie sich 1/3 in Basis 10 endlos wiederholt (0.3333...). Ausgeschrieben beginnt 0.1 binär so:

1

0.1₁₀ = 0.000110011001100110011...₂  (wiederholt sich endlos)

Keine endliche Anzahl Bits schneidet diese Folge so ab, dass genau 0.1 herauskommt. Ein 64-Bit-„Double" nach IEEE 754 (1 Vorzeichenbit, 11 Exponentenbits, 52 gespeicherte Mantissenbits, 53 Bit Genauigkeit mit der impliziten führenden 1) rundet die unendliche Entwicklung auf den nächsten darstellbaren Wert, der immer ein Bruch der Form J / 2^N ist. Für 0.1 ist dieser Wert:

1

3602879701896397 / 2^55

Als Dezimalzahl ist das 0.1000000000000000055511151231257827021181583404541015625. Python zeigt es Ihnen. Jedes Codebeispiel in diesem Artikel nutzt nur die Standardbibliothek. Sie brauchen also keine virtuelle Umgebung, um mitzumachen:

1
2
3
4

>>> (0.1).as_integer_ratio()
(3602879701896397, 36028797018963968)
>>> 0.1 == 0.1000000000000000055511151231257827021181583404541015625
True

0.2 bringt seinen eigenen, leicht anderen Rundungsfehler mit. Addieren Sie die beiden schon unperfekten Werte, dann heben sich die Fehler nicht auf, sondern summieren sich zu einem Ergebnis, das einen Schritt über dem Double liegt, das 0.3 am nächsten kommt. Daher 0.30000000000000004.

Welche Zahlen Gleitkomma wirklich exakt speichert

Nicht jede Dezimalzahl ist verloren. Ein Binärbruch endet, wenn sein Nenner, vollständig gekürzt, eine Zweierpotenz ist. 0.5 ist 1/2. 0.25 ist 1/4. 0.125 ist 1/8. Die sind exakt:

1
2
3
4

>>> 0.5 + 0.25 == 0.75
True
>>> 0.1 + 0.2 == 0.3
False

Die Dezimalzahlen, die Menschen tatsächlich eintippen, etwa Preise und Prozentsätze, haben fast nie einen Nenner, der eine Zweierpotenz ist. Das macht den Fehler bei 0.1 + 0.2 zum Normalfall von Dezimal-Arithmetik auf binären Floats, und er summiert sich. Addieren Sie 0.1 zehnmal in irgendeiner Sprache, die Doubles verwendet, so landen Sie nicht bei 1.0:

1
2
3
4
5

>>> total = 0.0
>>> for _ in range(10):
...     total += 0.1
>>> total
0.9999999999999999

Zehn Additionen reichen dafür. Beachten Sie: Die Big-O-Notation sagt, wie schnell diese Schleife mit der Eingabegröße wächst, aber nichts darüber, ob das Ergebnis stimmt – die Korrektheit ist hier eine eigene Prüfung, die Sie selbst vornehmen müssen.

Wie Sie Gleitkommazahlen sicher vergleichen

Da == bei Floats nicht zuverlässig ist, vergleichen Sie mit einer Toleranz: Prüfen Sie, ob zwei Zahlen nah genug beieinander liegen, statt identisch zu sein. Jede verbreitete Sprache hat dafür ihr eigenes Idiom.

In Python:

1
2
3
4
5

>>> import math
>>> 0.1 + 0.1 + 0.1 == 0.3
False
>>> math.isclose(0.1 + 0.1 + 0.1, 0.3)
True

math.isclose skaliert seine Toleranz an die Größe der Zahlen (rel_tol * max(abs(a), abs(b))), sodass derselbe Aufruf bei kleinen und großen Größenordnungen funktioniert. Der Standardwert für abs_tol ist allerdings 0.0. Kann einer der beiden Werte legitim null oder sehr nah daran sein, übergeben Sie ein explizites abs_tol – sonst schlägt der Vergleich bei Werten fehl, die Sie für gleich halten würden.

Number.EPSILON in JavaScript (2⁻⁵², etwa 2.22e-16) ist der Abstand zwischen 1 und dem nächsten darstellbaren Double, also für sich allein nur bei Zahlen nahe 1 ein gültiger Schwellenwert. Skalieren Sie ihn für alles andere:

1
2
3
4
5

function nearlyEqual(x, y, scale = 1) {
  return Math.abs(x - y) < Number.EPSILON * scale;
}
nearlyEqual(0.1 + 0.2, 0.3);              // true
nearlyEqual(1000.1 + 1000.2, 2000.3, 2000); // true, die Skala passt zur Größenordnung

Eine Assertion wie result == 0.3 in einem Test ist ein Bug, der nur auf eine andere Eingabe, Plattform oder einen anderen Compiler wartet, um sichtbar zu werden. Ob Unit-Test oder weiter oben in der Testpyramide – ersetzen Sie den exakten Vergleich durch eine Toleranzprüfung.

Wenn Gleitkomma das falsche Werkzeug ist: Geld und Zählwerte

Eine Toleranz behebt den Vergleich. Sie behebt nicht die Speicherung. Wenn Sie Preise aufsummieren oder einen laufenden Kontostand führen, ist der Rundungsfehler selbst das Problem, und die Lösung ist, für diesen Wert kein float/double mehr zu verwenden.

Die einfachste Variante: Geld als Ganzzahl der kleinsten Einheit speichern. 19,99 € sind die Ganzzahl 1999 Cent, nicht der Float 19.99. Addition und Subtraktion zwischen Ganzzahlen haben keinen Rundungsfehler. Wandeln Sie erst beim Anzeigen des Werts in einen Dezimalstring um.

Brauchen Sie echte Dezimalbrüche mit exakten Rundungsregeln (eine Buchhaltung, eine Steuerberechnung, alles, was auf den Cent aufgehen muss), nutzen Sie einen Dezimaltyp:

1
2
3

>>> from decimal import Decimal
>>> Decimal("0.1") + Decimal("0.2") == Decimal("0.3")
True

Java hat dafür BigDecimal; C# hat einen nativen 128-Bit-Typ decimal mit etwa 28-29 signifikanten Dezimalstellen. Alle drei speichern Ziffern zur Basis 10, sodass die Dezimalbrüche, die Menschen schreiben, ohne Rundung gespeichert werden. Dafür zahlen Sie mit Geschwindigkeit und Umständlichkeit. Dezimaltypen sind langsamer als native Floats und brauchen bei der Division einen expliziten Rundungsmodus. Für einen Bankkontostand lohnt sich das. Für eine zahlenintensive Schleife ist es ein schlechter Tausch.

Wenn die Ungenauigkeit von Gleitkomma keine Rolle spielt

Grafiktransformationen, physikalische Simulationen, Gewichte von Machine-Learning-Modellen und Audioverarbeitung laufen absichtlich auf Floats. Ein relativer Fehler um 1e-16 liegt weit unter dem, was diese Bereiche überhaupt bemerken könnten, und native Float-Hardware ist deutlich schneller als Dezimal-Arithmetik.

Die Frage zu einer Zahl ist also nicht, ob sie ein Komma hat. Fragen Sie sich, ob Sie diskrete, exakte Dinge zählen, etwa Geld oder das erwartete Ergebnis eines Tests, oder eine kontinuierliche Größe messen, die von Anfang an ungefähr war, etwa eine Pixelposition oder einen Sensorwert. Gezählte Werte brauchen Ganzzahlen oder einen Dezimaltyp. Gemessene Werte sind genau das, wofür Gleitkomma gebaut wurde, und sie auf Decimal umzustellen macht sie nur langsamer, ohne sie nennenswert korrekter zu machen.

Wenn Sie das nächste Mal ein als float deklariertes Saldofeld sehen oder einen Test, der result == 0.3 behauptet, entscheiden Sie, um welche Art Zahl es sich handelt, und korrigieren Sie den Speichertyp oder den Vergleich gleich in dieser Review – bevor ein fehlender Cent in der Produktion auftaucht.

Verwandte Artikel

• Big-O-Notation Erklärt mit Code-Beispielen
• Unit-Tests vs Integrationstests vs End-to-End-Tests
• Virtuelle Python-Umgebungen: venv, pip und uv