Im Jahr 2007 sorgte ein mysteriöser Fehler in der damals neuesten Version von Microsoft Excel, Excel 2007, für Aufsehen. Was auf den ersten Blick wie ein fundamentales Problem mit der Rechengenauigkeit erschien, war tatsächlich ein faszinierendes Zusammenspiel aus binärer Zahlendarstellung und einer spezifischen Anzeige-Fehlfunktion. Wenn man beispielsweise 77,1 mit 850 multiplizierte, erwartete man das korrekte Ergebnis 65.535, doch Excel zeigte stattdessen 100.000 an. Dieser [Excel Berechnungsfehler] war verwirrend und führte zu vielen Diskussionen in der Tech-Welt.
Dieses Phänomen wirft wichtige Fragen über die interne Funktionsweise von Tabellenkalkulationsprogrammen und die Komplexität der Darstellung von Zahlen auf Computern auf. In diesem Artikel tauchen wir tief in die Materie ein, um zu verstehen, warum dieser Excel Fehler 2007 auftrat, welche Rolle die Gleitkomma-Arithmetik spielt und wie Microsoft mit einem solchen unerwarteten Fehler umging.
Excel intern: Binärdarstellung und Anzeige
Um den Kern des Problems zu verstehen, muss man wissen, wie Excel Zahlen intern verarbeitet. Obwohl wir Zahlen wie 77,1 im Dezimalsystem eingeben und sehen, speichert Excel sie intern in einem binären Format, typischerweise mit 64 Bit. Diese binäre Darstellung ist eine Abfolge von Nullen und Einsen, die die Zahl im Computersystem repräsentieren.
Wenn Sie beispielsweise 77,1 eingeben, wird es intern als eine spezifische 64-Bit-Sequenz gespeichert. Die Anzeige auf dem Bildschirm ist jedoch eine völlig andere Operation: Excel wandelt die interne Binärzahl in eine Zeichenfolge um, die aus den Ziffern “7”, “7”, “.”, “1” besteht.
Der Fehler von 2007 lag nicht im Kern der Rechenmaschine von Excel, sondern in der Funktion, die diese internen Binärzahlen für die Anzeige in Zeichenfolgen umwandelt. Es war ein spezifischer Anzeigefehler, der dazu führte, dass einige Zahlen, die extrem nahe an 65.535 lagen, fälschlicherweise als 100.000 formatiert wurden. Interessanterweise, wenn diese scheinbar fehlerhafte Zahl in weiteren Berechnungen verwendet wurde, lieferte Excel korrekte Ergebnisse. Addierten Sie beispielsweise 2 zum Ergebnis von 77,1 * 850, so zeigte Excel 65.537 an, was korrekt war.
Die Illusion von 100.001: Eine verwandte Fehlfunktion
Der Excel Fehler 2007 war nicht auf die Zahl 65.535 beschränkt. Eine ähnliche Fehlfunktion existierte auch für einige Zahlen, die extrem nahe an 65.536 lagen, welche dann fälschlicherweise als 100.001 angezeigt wurden. Wenn beispielsweise 77,1 * 850 + 1 berechnet wurde, zeigte Excel in diesen speziellen Fällen 100.001 an, obwohl das korrekte Ergebnis 65.536 wäre.
Es ist wichtig zu betonen, dass dies weiterhin ein reiner Anzeigefehler war. Selbst wenn eine Zahl im Arbeitsblatt falsch angezeigt wurde, würde ein Diagramm, das auf dieser Zahl basierte, die korrekten Werte widerspiegeln. Dies verdeutlicht, dass die zugrunde liegende Berechnung korrekt war und lediglich die visuelle Darstellung auf dem Bildschirm fehlerhaft war.
Warum 77.1 * 850 nicht genau 65.535 ist: Das Problem der Gleitkommazahlen
An dieser Stelle mag sich die Frage stellen: Wenn 77,1 * 850 exakt 65.535 ergeben sollte, warum reden wir dann von Zahlen, die “extrem nahe” an 65.535 liegen? Die Antwort liegt in der Natur der Gleitkomma-Arithmetik und der binären Zahlendarstellung.
Das Problem ist, dass viele Dezimalzahlen, insbesondere solche mit Nachkommastellen wie 0,1, keine exakte Repräsentation im Binärsystem haben. Dies ist vergleichbar damit, wie 1/3 keine exakte dezimale Darstellung hat – es ist eine unendliche Folge von 0,3333… Wenn man diese unendliche Darstellung bei einer bestimmten Anzahl von Ziffern abschneidet, führt dies zu kleinen, unbedeutenden Rundungsfehlern am Ende der Nachkommastellen. Dasselbe gilt für andere Dezimalzahlen wie 0,2, 0,3, 0,4, 0,6, 0,7, 0,8 und 0,9 im Binärsystem (aber nicht für 0,5).
Die meisten modernen Computersysteme, einschließlich Excel, verwenden den IEEE 754-Standard zur Darstellung von Gleitkommazahlen. Dieser Standard ist seit langem etabliert und bedeutet, dass bei mathematischen Operationen mit solchen Zahlen gelegentlich Ungenauigkeiten auftreten können. Diese Ungenauigkeiten sind in der Regel so gering, dass sie bei einer sinnvollen Rundung der Zahlen keine Rolle spielen.
Da 77,1 keine exakte binäre Darstellung hat, speichert Excel es mit einer minimalen Ungenauigkeit. Wenn diese inexakt gespeicherte Zahl dann mit 850 multipliziert wird, ergibt sich ein Ergebnis, das nicht exakt 65.535 ist, sondern nur sehr, sehr nahe daran. Und genau diese geringfügig abweichende Zahl war eine von nur zwölf möglichen Gleitkommazahlen, die diesen spezifischen Anzeigefehler in Excel auslösten. Es war also eine unglückliche Kombination aus den inhärenten Grenzen der Gleitkomma-Arithmetik und einem Fehler in der Zahlenformatierungs-Engine von Excel.
Häufig gestellte Fragen zum Excel-Bug
F: Ist dieser Fehler wirklich so gravierend?
Meiner Einschätzung nach ist die Wahrscheinlichkeit, dass dieser Fehler in realen Berechnungen von Bedeutung ist, verschwindend gering. Die Chancen, davon tatsächlich betroffen zu sein, sind so klein, dass man sich eher Sorgen machen sollte, von einem Meteoriten getroffen zu werden. Obwohl Microsoft natürlich betonen musste, dass “Genauigkeit für uns extrem wichtig ist” und schnell einen Fix bereitstellte, war die praktische Auswirkung für den einzelnen Nutzer minimal.
F: Sollte nicht auf solche Fehler getestet werden?
Ich gehe davon aus, dass ein Großteil der numerischen Tests im Excel-Team automatisiert mit VBA-Code durchgeführt wird. Zellen, die diesen fehlerhaften Wert enthielten, zeigten zwar 100.000 an, doch aus VBA heraus würden sie als 65.535 erscheinen (da die Zahl binär an die Basic-Laufzeitumgebung übergeben würde, bevor die Anzeigeformattierung erfolgte). Es gibt sicherlich viel Code zur Überprüfung der Anzeigeformattierung, aber bei einem Fehler, der nur bei 12 von 18.446.744.073.709.551.616 möglichen Gleitkommazahlen auftritt, ist es unwahrscheinlich, dass ein Satz von Black-Box-Tests diesen Fall abdecken würde.
F: Was war die Ursache des Fehlers?
Ohne den genauen Code lässt sich das nicht mit Sicherheit sagen. Aus dem Stegreif fällt mir nichts ein, was dieses Verhalten direkt verursachen würde. Möglicherweise hängt es mit komplexen Randfällen im Zusammenhang mit dem IEEE 754-Standard zusammen.
F: Warum keine “exakte” (dezimale) Arithmetik?
Exakte dezimale Arithmetik ist wesentlich langsamer als Gleitkomma-Arithmetik, da es auf den meisten CPU-Chips keine native Hardwareunterstützung dafür gibt. In der Vergangenheit erhielt Microsoft so viel Kritik wegen Gleitkomma-Rundungsartefakten im Windows-Rechner, dass dieser umgeschrieben wurde, um eine Bibliothek für beliebige Präzisionsarithmetik zu verwenden. Da der Windows-Rechner nicht so schnell sein muss wie Excel, war das eine praktikable Lösung. Allerdings sind CPUs heutzutage so schnell geworden, dass eine Arbiträrpräzisions-Version von Excel wahrscheinlich recht gut funktionieren würde. Dennoch hat das Microsoft Excel Support-Team die letzten 20 Jahre damit verbracht, den IEEE 754-Standard zu verteidigen, und es ist nicht verwunderlich, dass sie daran zu glauben begonnen haben. Angesichts der Komplexität moderner Software ist es auch eine Überlegung wert, ob man die Kernberechnungs-Engine eines so kritischen Tools wie Excel leichtfertig umschreiben sollte. Die Aufrechterhaltung der Stabilität bestehender verlässliche Softwarelösungen ist oft wichtiger als die Implementierung neuer, potenziell fehleranfälliger Ansätze.
Fazit
Der Excel-Bug 2007 war ein bemerkenswertes Beispiel dafür, wie komplexe interne Computerarchitekturen und Anzeigelogiken zu unerwarteten Fehlern führen können. Er zeigte, dass selbst in scheinbar einfachen Rechenaufgaben tieferliegende technische Details wie die binäre Darstellung von Gleitkommazahlen und die IEEE 754-Standards eine entscheidende Rolle spielen können. Während der Fehler für Aufsehen sorgte und schnell behoben wurde, war seine tatsächliche Auswirkung auf die meisten Nutzer gering. Er diente jedoch als eine wertvolle Erinnerung an die Feinheiten der Softwareentwicklung und die ständige Notwendigkeit, sowohl die Logik der Berechnung als auch die Präsentation der Ergebnisse sorgfältig zu überprüfen.