Stellen Sie sich vor, Sie haben eine umfangreiche wissenschaftliche Berechnung zu programmieren. Unter vielen Formeln, die Sie in ein Computerprogramm umsetzen müssen, ist auch die Lösung einer quadratischen Gleichung. Genau, x²+px+q=0, x ist gesucht, und die Koeffizienten p und q kennen Sie zwar nicht im Voraus, aber das Programm hat sie soeben ausgerechnet. Wie ging das doch gleich?

Da gab’s eine Formel mit dem zweifelhaften Ehrentitel "Mitternachtsformel". Wer sie nicht mehr auswendig weiß, kann sie nachschlagen: x_1,2= – p/2 ± Wurzel (p²/4 – q). Na schön, dann programmieren Sie die Mitternachtsformel und machen sich noch Gedanken darüber, welches der beiden Vorzeichen in diesem Kontext das richtige ist ...

Stopp! Welchen fatalen Fehler haben Sie gerade eben gemacht? Nicht nachgesehen, ob das Ding unter der Wurzel (wie hieß das noch? Richtig, Diskriminante) vielleicht negativ wird und man über komplexe Lösungen nachdenken muss? Ja, da muss man aufpassen, aber wenn Sie das nicht tun, fällt das sofort auf, weil das Programm bei den ersten Testläufen mit einer Fehlermeldung abbricht. Nein, der wirklich heimtückische Fehler besteht darin, die Mitternachtsformel anzuwenden!

Es könnte nämlich vorkommen, dass p sehr groß ist (sagen wir, positiv) und q sehr klein. (Was niemand merkt, denn man bekommt p und q ja nie zu Gesicht, wenn man nicht ausdrücklich danach fragt.) Dann kommt bei der Wurzel, weil q kaum ins Gewicht fällt, fast genau p/2 heraus, und x₁ ist die Differenz zweier fast gleicher Größen. Da kommen erst einmal ein paar Nullen hinterm Komma und dann noch ein paar gültige Ziffern.

Was macht der Computer damit? Er macht, sagen wir, aus 0,000073845 die Darstellung 7,3845·10^–5, verschiebt das Komma also so, dass vor dem Komma eine Ziffer ungleich null steht, und merkt sich im Exponenten –5, um wie viele Stellen er es verschoben hat. Das ist die geläufige Gleitkommadarstellung. (Rechnerintern geht es mit Zweier- statt mit Zehnerpotenzen, aber das Prinzip ist dasselbe.) Sie erlaubt es, große wie kleine Zahlen mit der stets gleichen Anzahl an gültigen Ziffern zu rechnen. Standardmäßig sind für eine Gleitkommazahl 8 Byte vorgesehen, was auf eine Genauigkeit von ungefähr 16 Dezimalziffern hinausläuft.

Nur: Wenn zwei fast gleiche Zahlen subtrahiert werden, fängt das Ergebnis mit ein paar Nullen an, nämlich da, wo die beide Zahlen noch gleiche Ziffern hatten, und es bleiben weniger gültige Stellen übrig. Beim Kommaverrutschen füllt der Computer die Zahl hinten auf, mit Nullen oder weiß der Himmel was, jedenfalls nicht mit ernstzunehmender Information. Wenn das im Verlauf einer längeren Rechnerei mehrfach passiert, ist vom Endergebnis keine einzige Ziffer mehr glaubwürdig.

Die Gemeinheit ist: Es kommt am Ende nicht immer Unfug heraus (die Auslöschung gültiger Ziffern passiert ja nur manchmal), und wenn Unfug herauskommt, findet man keinen Programmierfehler als Ursache: Die Mitternachtsformel ist ja richtig.

Das ist alles Standardstoff einer ordentlichen Kursusvorlesung "Numerische Mathematik I". Wie kommt William Kahan, längst (von der University of California in Berkeley) emeritiert, dazu, die Probleme der Gleitkommarechnung vor 200 Jungforschern auf dem "Heidelberg Laureate Forum" auszubreiten? Weil er selbst 1985 an der Ausarbeitung des gültigen Standards IEEE 754 für das Rechnen mit Gleitkommazahlen maßgeblich beteiligt war und unter anderem dafür 1989 mit dem Turing Award ausgezeichnet wurde? Nicht wirklich. Der Hauptgrund ist, dass das Problem fortdauert.

Die Tücken der Gleitkommaarithmetik lauern in jeder größeren numerischen Berechnung: Wetter; Klima; Stabilität von Brücken und anderen Großbauwerken; Bewegung eines Flugzeugs und der umgebenden Luft, samt Strömungsabriss ("stall") und anderen unangenehmen Systemzuständen; Verhalten eines Kernkraftwerks im Störungsfall ... Natürlich ist man in vielen Einzelfällen unplausiblen Ergebnissen nachgegangen, hat die problematischen Rechenschritte entdeckt und durch bessere ersetzt. Aber nach wie vor ist ausgerechnet das Unternehmen, bei dem es um totale Berechenbarkeit in jedem Schritt geht, so unberechenbar wie eine Dschungelexpedition: Die Gefahren, die man kennt, sind nur eine untere Abschätzung für die Gefahren, die tatsächlich drohen. Wenn dein Vorgänger vom Tiger gefressen wurde, weißt du nur, dass du dich vor Tigern in Acht nehmen musst; du hast aber keine Ahnung, wie viele Tiger im Dschungel herumlaufen und wer dir sonst noch ans Leder will.

Zu allem Überfluss hat sich das Problem seit 1985 deutlich verschärft, und zwar aus eigentlich erfreulichen Gründen. Heute kann man sich viel Programmierarbeit ersparen, indem man fertigen Programmtext aus dem Internet holt. Aber natürlich weiß man nicht (und hat keine Chance herauszufinden), ob der Autor Numerik I gehört und verstanden hat. Und neuerdings nutzt man gerade für umfangreiche numerische Rechnungen gerne zweckentfremdete Grafik-Controller. Die können nur gewisse Dinge rechnen, die dafür aber sehr schnell – so weit schön und gut. Aber sie rechnen mit verringerter Genauigkeit; mehr ist für die Bildschirmdarstellung nicht erforderlich. Und bei 6 statt 16 Dezimalstellen wird das Problem mit der Auslöschung sehr schnell akut ...

Nach dem Horrorgemälde dürfen die Rettungsvorschläge nicht fehlen. Was tun? Nur denjenigen ans Programmieren lassen, der einen qualifizierten Schein in Numerik I vorweisen kann? Nette Idee, sehr deutsch, nur vollkommen unrealistisch. Aber Kahan gibt den Jungforschern den Rat an die Hand: "Seht wenigstens zu, dass ihr selber die Theorie beherrscht." Es gibt ja Abhilfen gegen die Auslöschung. Nur ist das in jedem Einzelfall eine andere, und meistens muss man intensiv in das Problem einsteigen, zu dessen Lösung die gefährliche Rechenoperation diente. Bei der quadratischen Gleichung hilft ein bisschen Algebra (vietascher Wurzelsatz); andere Anwendungen erfordern vielleicht eine ganz neue Theorie.

Einen konkreten Vorschlag hat Kahan dann doch: Man setze die Standardgenauigkeit für das Gleitkommarechnen hoch. 16 statt 8 Byte für eine Gleitkommazahl ist heute, wo Platz für Speicher und Rechenwerk nicht mehr knapp ist, technisch kein Problem. Wenn die entsprechenden Operationen in Hardware zur Verfügung stehen, dauert es auch nicht mehr so quälend lange, wie wenn man denselben Vorgang mit jeweils zwei gewöhnlichen Gleitkommazahlen – eine für die vorderen, die andere für die hinteren Ziffern – in Software realisiert. Sicher ist das Kurieren an Symptomen. Aber es würde gegen jeden Verlust von weniger als 16 gültigen Dezimalziffern helfen, und was darüber hinausgeht, ist schon sehr ungewöhnlich. Zu ärgerlich, dass Kahan seinen Vorschlag auf der letzten Standardisierungssitzung 2008 nicht durchgekriegt hat.

Ein anderer Vorschlag bezieht sich auf das "error handling". Wenn ein Programm auf eine nicht ausführbare Rechenoperation stößt – Division durch null, Wurzel aus einer negativen Zahl oder so –, pflegt es mit einer entsprechenden Fehlermeldung abzubrechen. Das war sinnvoll zu einer Zeit, als Programme um knappe Zeit auf einem zentralen Großrechner konkurrierten und ein fehlerhaftes Programm ansonsten die ganze Maschine blockiert hätte. Heute kann dieses Verfahren mitunter tödlich sein.

Kahan erzählt ausführlich von dem Absturz des Air-France-Flugs 447 über dem Atlantik in der Nacht vom 31. Mai auf den 1. Juni 2009, bei dem alle Insassen ums Leben kamen. In stockfinsterer Nacht gerät die Maschine in ein heftiges Gewitter – unangenehm, aber nicht lebensbedrohlich. Aus der extrem feuchten Luft kondensieren Eiskristalle und verstopfen das Staurohr, das zur Geschwindigkeitsmessung dient. Der Bordcomputer erkennt, dass die vom Staurohr gemeldete Geschwindigkeit nicht mit den übrigen Messwerten in Übereinstimmung zu bringen ist, und bricht aufgrund dieser Fehlermeldung sein Standardprogramm ab. Die Piloten wissen, dass man in solchen Situationen die Meldungen des Bordcomputers nicht mehr für voll nehmen kann. Daher ignorieren sie auch die "Stall"-Warnung; die aber kommt von noch intakten Teilen des Systems und ist durchaus zutreffend. Zu allem Überfluss sinkt durch die Manöver der Piloten die Maschine in wärmere Luftzonen, das Eis schmilt, das Staurohr misst wieder richtig; aber der Bordcomputer kehrt nicht in den Normalzustand zurück. Da die Piloten nach wie vor kein klares Bild von der Situation bekommen, bleibt das voll funktionsfähige Flugzeug zu steil angestellt, verliert rapide an Höhe, schlägt mit hoher Geschwindigkeit auf der Meeresoberfläche auf und zerbricht.

Aus dieser und ähnlichen Erfahrungen zieht Kahan den Schluss, dass ein schlichter Programmabbruch bei Fehlermeldungen durch intelligentere Verfahren zu ersetzen sei. "There are better ways."

Nach Kahans Vortrag entspinnt sich eine Diskussion, an der sich vor allem seine Altersgenossen überaus lebhaft beteiligen. Erstaunlich viele Leute wissen von eigenen Erfahrungen mit der CDC 6600 zu berichten, dem ersten enstzunehmenden Supercomputer, der ab 1964 produziert wurde. Der machte die Normalisierung (das Zurechtrücken des Kommas) nicht nach jedem Rechenschritt, sondern, um Rechenzeit zu sparen, nur dann, wenn es sich nicht mehr vermeiden ließ. Und prompt kam bei den Wettersimulationen etwas anderes heraus als zuvor. Was machten die Wetterrechner? Sie schauten nicht etwa nach, wo in ihren Programmen etwas faul war, sondern bestanden darauf, dass dasselbe herauskommen müsse wie zuvor, und waren zufrieden, als die Maschine nicht neu-falsch, sondern wieder alt-falsch rechnete.

Ob denn die Intervallarithmetik helfen könne? Bei diesem Verfahren tut man nicht so, als kennte man seine Zahlen genau, sondern stellt sie gleichsam mit Fehlerschranken dar. An Stelle jeder Zahl steht ein Paar aus unterer und oberer Grenze; dazwischen liegt garantiert der "echte" Wert, und diese Garantie pflanzt sich über alle einzelnen Rechenschritte fort. Das sei ein wundervolles Verfahren für eine ganz spezielle Problemklasse, erwidert Kahan, nämlich stark kontrahierende Fixpunktabbildungen zu berechnen. Im Allgemeinen seien die Intervallabschätzungen pessimistisch bis zur Unbrauchbarkeit. Was habe ich davon, wenn ich wissen will, ob das Wasser kocht, und das Programm garantiert mir, dass die Temperatur zwischen 50 und 250 Grad liegt?

Und ob Kahan nicht auch finde, dass die Neuauflage des IEEE-Standards 754 beim Lesen heftiges Kopfweh erzeuge? Allerdings, erwidert er und weiß aus dem Nähkästchen zu plaudern. Da hätten einige Kommissionsmitglieder ihre persönlichen Steckenpferde geritten (Dezimalarithmetik zum Beispiel), mit dem Effekt, dass das ganze Dokument monströs und unverständlich geraten sei. Eigentlich müsste man sich hinsetzen und das ganze Ding in menschenlesbare Sprache umschreiben. Aber Kahan bittet um Verständnis, dass er das nicht mehr tun werde. Er sei schon 80 und habe andere Prioritäten.