Ratschläge für das richtige Runden

BLOG: Heidelberg Laureate Forum

Laureates of mathematics and computer science meet the next generation
Heidelberg Laureate Forum

Donnerstag morgen endlich hielt William Morton Kahan seinen Vortrag, auf den ich schon sehr gespannt war. Der Titel “Desperately needed remedies for the undebuggability of large-scale floating-point computations in science and engineering”, der gut als Abstract durchgeht, war mir gleich im Programm aufgefallen.

Von meinen Recherchen wusste ich, dass Kahan wichtige Arbeiten auf dem Gebiet numerisch robuster Verfahren geleistet hat und unter anderem an der Entwicklung des Gleitkomma-Standards IEEE 754 beteiligt war. Er sagte gleich zu Beginn, dass er lieber über partielle Differentialgleichungen gearbeitet hätte, seine Arbeit zur Vermeidung von Gleitkomma-Rundefehlern jedoch wichtiger waren. Zum Glück wurde die Wichtigkeit dieser aus Sicht der Mathematik eigentlich unnötigen Arbeiten erkannt und er mit dem Turing-Award ausgezeichnet.

William Morton Kahan
©HLFF, Christian Flemming

Kahan hatte mehrere wichtige Botschaften. Als erstes wies er darauf hin, dass ziemlich sicher unnötige Rundungsfehler sehr viel häufiger vorkommen als angenommen. Grund ist einerseits, dass diese Fehler nur auffallen, wenn sie drastische, offensichtliche Auswirkungen haben und andererseits viele Programmierer (und ich bin da leider keine Ausnahme) mit den notwendigen Analyse-Techniken noch nicht vertraut sind. Er skizzierte kurz diese Techniken, die ich mir in jedem Fall genauer anschauen will.

Letztlich sieht er zwei Auswege aus der Problematik der Rundungsfehler: Die erste, von ihm zu Recht als humanere bezeichnete, besteht darin, Gleitkommazahlen mit höherer Genauigkeit zu verwenden. Leider führt der seit einigen Jahren bestehende Trend, Computer eher nach den weniger Genauigkeit verlangenden Unterhaltungsanwendungen zu entwickeln, oft zum Gegenteil: Viel Rechenleistung gibt es nur für 4-Byte-Gleitkommazahlen statt der im wissenschaftlichen Rechnen üblichen 8-Byte-Gleitkommazahlen. Kahan hingegen empfiehlt die Verwendung von 16-Byte-Gleitkommazahlen, wofür allerdings die für Effizienz nötige Hardware-Unterstützung nicht absehbar ist. Als Alternative bleibt daher nur die gründliche Analyse von Programmen, für die er ein hilfreiches Werkzeug zum Auffinden potenziell kritischer Programmteile vorschlug.

Schließlich ging er auf ein weiteres Problem in diesem Zusammenhang ein: Die Behandlung von Fehlern, also zum Beispiel einer versuchten Division durch 0. Sehr eindringlich schilderte er die Ursache des Absturzes des Air-France-Flugs AF447 über dem Atlantik im Mai 2009. Zumindest zum Absturz beigetragen hat eine Fehlermeldung, die nur “invalid data” meldete und den Piloten keinerlei Hinweis gab, welche Sensordaten unbrauchbar waren. Kahan hat auf seiner Webseite eine Reihe anderer Beispiele, wo Gleitkomma-Fehler zu Katastrophen oder zumindest kritischen Zuständen geführt haben.

Es war sehr beeindruckend, als Vinton Cerf, ein anderer Turing-Preisträger, aufstand und sagte, dass er sich in seiner Position als Präsident der ACM (amerikanische Gesellschaft für Informatik) dafür einsetzen wird, die Situation zu verbessern. Und für die Nachwuchswissenschaftler hatte Kahan noch eine Botschaft, die gut zur Idee des HLF passt: “Look, there is so much to do and I am 80. You’ll have to do it.”


Zum Reinhören: Der Vortrag von William Kahan während des HLF13

Avatar photo

Posted by

ist promovierter Mathematiker und forscht in der Abteilung Optimierung des Konrad-Zuse-Instituts in Berlin. Dort leitet er die Arbeitsgruppe Energie, die sich vor allem mit Optimierungsproblemen für Gasnetze befasst. Zum Bloggen für das HLF kam er als Klaus-Tschira-Preisträger für verständliche Wissenschaft “KlarText!”.

4 comments

  1. Um das Gleitkommarechnen innerhalb von Computerprogrammen zu verbessern muss es zuerst einmal ein Bewusstsein für das Problem geben und zudem praktische Mittel um es zu vermeiden. Der Umstieg auf 16-Byte-Gleitkommastellen hätte sicher den Vorteil der automatischen Verbesserung ohne dasse in einziges Programm umgeschrieben werden müsste. Zur Not könnte man aber die gleichen Routinen einmal mit den eingebauten Gleitkommaassemblerbefehlen und einmal in Software bei höherer Genauigkeit durchrechnen. Noch besser wäre natürlich ein Programm, dass die Software analysieren und Hinweise auf möglche Verluste an Gleitkommagenauigkeit geben könnte. Erste Versuche in diese Richtung gibt es. Siehe zum Beispiel hier: http://www.cdl.uni-saarland.de/papers/benz_fp.pdf
    Automatische Programmprüfer und Verifizierer sollten mindestens in sicherheitskritischen Bereichen immer mehr eingesetzt werden. Auch Überprüfungen der Gleitkommaalgorithmen gehören meiner Ansicht nach zu den sicherheitsrelevanten Bereichen.

  2. Wenn mit reellen Zahlen gearbeitet wird, so bleiben diese ableitbar aus den rationalen Zahlen, insofern wären reelle Zahlen als Funktion zu gießen und das Rechnen mit reellen Zahlen wäre eine Anforderung an entsprechende Funktionen mit angeforderter Nachstellen-Genauigkeit zu liefern.

    Auch das Persistieren von Datenlagen, die reelle Zahlen einschließen, könnte derart erfolgen.

    Die Datenhaltung würde denn -wenn’s auf die Genauigkeit ankommt- Funktionen halten, nicht Näherungen.

    MFG
    Dr. W

    • Mein Vorschlag Gleitkommaoperationen zu Überprüfungszecken in Software auszuführen, die mit höherer Genaigkeit rechnet, entspricht diesem Vorschlag einer “funktionalen” Ausführung. Im Idealfall könnte bestehender unmodifizierter Code im Testmodus mit höherer Rechengenaigkeit und mit einem größeren Gleitkommadatentyp arbeiten.
      Doch eine “Silver bullet” ist das nicht. Letzlich kann man auf die Effizizenz, die die heutigen Gleitkommazahlenformate bieten, nicht verzichten. Deshalb mein zweiter Vorschlag, Gleitkommacode mittels Analysetool zu checken.

  3. Herr Holzherr, weder das Abstract noch die Conclusio des von Ihnen verlinkten Dokuments lädt direkt dazu ein dem Vorhaben beizutreten, zumindest auf diesen Feedback-Geber bezogen.
    Moderne Datenhaltung bearbeitet derartige Herausforderung denn auch mit dem DB-nahen Halten von Funktionen.
    Wie bspw. dem COBOL-Programmierer, der derartige Möglichkeiten nicht hat, der also an Mustervorgaben (“PIC-Klausel”) gebunden ist, sinnhaft beigesprungen werden kann, erschließt sich dem Schreiber dieser Zeilen nicht.

    MFG
    Dr. W (der eher am Rande noch bemerkt, dass die CAPTCHAs immer anspruchsvoller werden)

Leave a Reply


E-Mail-Benachrichtigung bei weiteren Kommentaren.
-- Auch möglich: Abo ohne Kommentar. +