Stefan Kanthak hat mich vor einigen Tagen auf unschöne Fehler in der GNU libc aufmerksam gemacht. Trigonometrische Berechnungen führen zu fehlerhaften Werten, die weit oberhalb dessen liegen, was Mathematiker als Abweichungen gefunden und bestätigt haben.
In einer Mail schrieb Kanthak: "Auf Unix/POSIX-Systemen stellt die 'libc' die von C-Programmen verwendeten Standardfunktionen sowie die Schnittstelle zwischen Benutzerprogrammen und Kernel bereit. Für mathematische (trigonometrische, transzendentale, etc.) Funktionen gibt es noch die 'libm'. Auf GNU/Linux bzw. GNU/*-Systemen stellt die GNU libc beides bereit." Laut Kanthak arbeitet nicht nur das CERN mit der GNU libm und vertraut den Ergebnissen.
Die Abweichungen bei den Ergebnissen
Es gibt eine Dokumentation 19.7 Errors in Math Functions, die sich mit den Fehlern in den mathematischen Funktionen befassen. Dort heißt es u.a.
Errors are measured in "units of the last place". […]
…
Each function with a floating-point result behaves as if it computes an infinite-precision result that is within a few ulp of the mathematically correct value of the function […]
…
the math testsuite only flags results larger than 9ulp (…) as errors; although most of the implementations show errors smaller than the limit.
Kanthak wies darauf hin, dass im Februar 2026 ein paar bekannte Mathematiker (u.a. Dr. Brian Gladman, Prof. Dr. Paul Zimmermann, …), die seit über 30 Jahren mit Gleitpunkt-Arithmetik "spielen", eine Untersuchung zur (Un)genauigkeit verschiedener
"libm"-Implementierungen veröffentlicht. Dort bescheinigen sie sie (fast) allen
mathematischen Funktionen der GNU libm einen maximalen Fehler von 0.5 ULP bescheinigen.
Es gibt Diskrepanzen bei den Ergebnissen
Kanthak schrieb mir, dass er diese obige Untersuchung nicht kannte. Bei eigenen "Spielereien" (Implementation von Payne/Hanek-Argumentreduktion) stieß er binnen Minuten auf das Problem, dass die Ergebnisse größer Abweichungsfehler zeigen.
- cos(214112296674652) weist einen Fehler von 179 ULP auf
- sin(1284673780047912) sowie
- tan(1284673780047912) weisen jeweils einen Fehler von 268 ULP auf.
Hätte noch ein Fehler von Kanthak sein können. Daher hat Kanthak bei <libc-maintainers@gnu.org> nachfragt, ob 179 ULP oder 268 ULP als "a few ulp" gelten. Darauf wird der französische Mathematiker Paul Zimmermann aufmerksam. Wenn ich es richtig gesehen habe, hat Zimmermann einiges zu Abweichungsfehlern in solchen Bibliotheken geschrieben. Im aktuellen Fall bestätigt Zimmermann die von Kanthak ermittelten "groben" Fehler in den trigonometrischen Funktionen.
Weitere Tests von Kanthak
Kanthak hat dann die natürlichen Zahlen 214112296674652 und 1284673780047912 als "fast Vielfaches" von pi, pi/2 oder pi/4 als sogenannte Konvergenten von pi verwendet. Der Zähler/Numerator des Bruchs 6134899525417045/1952799169684491, der 105 Bits bzw. 32 Dezimalstellen von pi liefert, ist ein solcher Konvergent. Zähler/Numerator und Nenner/Denumerator sind kleiner 2**53 und exakt als (doppelt genaue) Gleitpunktzahlen darstellbar.
Der Bruch 5920787228742393/3769290217798865 liefert 32 Dezimalstellen
von pi/2, der Bruch 6027843377079719/7674888557167847 liefert 32 Dezimalstellen
von pi/4.
Kanthak hat (der Einfachheit halber) nur Werte kleiner 2**53 = 0x1.0p+53 =
9007199254740992 verwendet, die als Gleitpunktzahlen EXAKT darstellbar
sind. Es gibt diese auch größer als 2**53. Dabei laufen die ULPs "weg, z.B. liefert:
- sin(0x1.4c96c11134d36p+578) einen Fehler von 102825 ULP,
- cos(0x1.69eab0985179bp+246) einen Fehler von 136921 ULP,
- tan(0x1.69eab0985179bp+246) einen Fehler von 143270 ULP
Das ist also mehr als das 10000-Fache dessen, was GNU als fehlerhaft betrachtet, bzw. das ist das 286000-Fache dessen, was die oben erwähnten Mathematiker als "größten gefundenen Fehler" in der Bibliothek angeben. Klingt nicht gut.
Nachtrag: Die libc-Maintainer haben Kanthak inzwischen mitgeteilt, dass sie diesen seit 2013 vorhandenen Fehler (in einer von IBM eingereichten Routine) in der im Oktober 2026 kommenden Version 2.44 behoben haben (siehe Bug 15267 und Bug 34376).
MVP: 2013 – 2016
Super-Interessant, aber für den Laien/Otto-Normalverbraucher leider nicht verständlich.
Wie und wo genau kann sich solches massives "verrechnen" positiv, negativ oder gar nicht auswirken?
– Dimensionierung von (Atom-, Wasser-, Wind-) Kraftwerksanlagen?
– Dimensionierung von (Raketen-/Weltraum) Triebwerken?
– Flugbahnberechnungen?
– Dimensionierung von Waffen, Munition & Bomben o.ä.
– Wettervorhersage
– Simulation von Auswirkungen von z.B. Stürmen (Wind, elektromagnetisch), Erdbeben und Tsunamis
– ????
Das wären jetzt so die Punkte, die UNS ALLE bei massiver negativer Fehlerhaftigkeit betreffen könnte bzw. würde.
Danke schön.
PS:
Erinnert mich an einen Bericht im Bekanntenkreis:
Der Bekannte hat ein ca. 15 Jahre altes Auto. Kürzlich bekam er ein Schreiben vom KBA, am Airbag (in diesem 15 Jahre alten Auto!) gibt es einen Fehler.
Er solle NICHT MEHR MIT DIESEM AUTO FAHREN, aber zeitnah zur nächsten Werkstatt fahren (!!), um den Fehler zu fixen …. Ähm … ja … 😊🤣
Um den Kreis zu obigem Artikel zu schließen:
Wieviel (wissenschaftlich/technische) Projekte wurden denn seit 2013 damit (ggf. fehlerhaft) berechnet und welche Projekte tangiert es?
Ist es notwendig, z.B. Brücken zu sperren o.ä. ?
Gar nicht, bis kaum. Es gibt Mathebibliotheken für echte Mathematik. Gerade in Spielen ist absolute Präzision quatsch, da rechenintensiv.
Python ohne Math-Lib:
>>> 0.1 + 0.2 =
0.30000000000000004
Das ist nunmal wie Floats arbeiten und in der IEEE 754 beschrieben. Wer bessere Resultate braucht nutzt eine Lib die das vermeidet. PCs sind so konzipiert bis runter auf HW-Ebene:
*https://www.righto.com/2025/01/pentium-floating-point-ROM.html
Bitte im Appendix den Konstantenspeicher des ROM ansehen.
Welcher Trottel schrob denn etwas von Spielen?
Beispielsweise IBM's , die korrekt gerundete, d.h. 0.5 ULP genaue trigonometrische Funktionen versprach, aus der die von GNU libc benutzte fehlerhafte Funktion zur Argumentreduzierung stammt?
Oder er verlässt sich auf von renommierten Wissenschaftlern veröffentlichte Untersuchungen, die den IEEE-754 binary64 Funktionen der GNU libc einen maximalen Fehler von 0.501 ULP attestieren?
Hör auf mit dem Dummschwatz!
Ja gut soviel zu zivilisiertem Verhalten online. Wäre die C-Standard-Bibliothek dafür geeignet würde es weder R noch Matlab geben. Ich habe auf diese Diskussion heute gerade absolut keine Lust.
Nicht die Konjugation von schreiben, aber das ist eine Offtop-Tangente.
Bitte las diese Wortwahl oder Ignoriere mich einfach. Nett sein kostet dich keinen Cent. Mir ist egal was eine Lib verspricht. Nichts was ich geschrieben habe ist falsch, es gefiel dir nur nicht, weil es die Wahrheit ist.
Wer arbitrary precision float point math will, der nutzt keine Standard-Bibliothek, bitte gehe mich nie wieder wegen sowas an. Das untergräbt allein die Arbeit jeder echten Math-Lib:
*https://mpmath.org/
Und das ist nur eine.
Welcher Trottel schrob von "arbitrary precision"? Du baus(chs)t hier STROHMÄNNER auf! Nochmal: hör auf mit dem Dummschwatz!
Manche Leute sollten erstmal Vorlesungen verfolgen oder Bücher zum Thema "Numerische Mathematik" lesen, bevor sie auf die Welt losgelassen werden. Darin geht es darum, wie digitale Rechner rechnen und welche Fehlerquellen es da alles gibt und die sich nicht komplett verhindern lassen. Gerade bei Floatingpoint-Zahlen mit vielen gewünschten Stellen hinter dem Komma wird es ganz am Ende richtig eklig… Wenn man es nämlich genau nimmt, rechnet kein digitaler Computer genau. Höchstens "genau genug", das ist immer ein Kompromiss. Ich kann da zwei Standardwerke empfehlen, die einem das genau erklären, warum digitale Berechnungen nie genau sind, zum einen "den Richter" und zum anderen "den Knorrenschild", gibts beide bei "A". Und damit kann man dann die Frage stellen, rechnet die "libm" richtiger, oder das "Ding", das die Gegenkontrolle machte? (Auch die weltbesten Taschenrechner rechnen digital)
Es stellt sich auch die Frage, welche Genauigkeit denn tatsächlich gebraucht wird.
Beispielsweise reicht für sehr viele Zwecke nur eine begrenzte Zahl an Nachkommastellen.
Im Alltag reicht z.B. bei der Zahl Pi 4 Nachkommastellen, also 3,1416, bei anderen Sachen dagegen müssen es schon 10 Nachkommastellen sein, also 3,1415926536 und im Höchspräzisionsbereich reichen auch die nicht aus.
Wobei man bemerken muss, das es keine analoge Welt gibt, auch wenn sie einem so erscheint.
Die digitalen Stufen der realen Welt sind aber so klein, das man sie nicht bemerkt (mehrere Trillionen Bit)
Stichwort Quantensprung.
Es gibt Energiezustände, die ein Quant nicht erreichen kann. Die Zustände springen zwischen festen Werten.
Und was Floating Point Berechnungen angeht:
Wegen der Rundungsgenauigkeit haben die Intel Coprozessoren eine höhere Bittiefe als die Hauptprozessoren.
Schon der Coprozessor Intel 8087, der für den 16-bittigen 8086 gedacht war, rechnet intern mit 80 bit, ist also ein 80bit-Prozessor.
— snip
Welcher Trottel *schrob* …
— snap
Was ist das denn für eine Sprache?
Definitiv *NICHT* deutsch. Die Vergangenheitsform von schreiben lautet *NICHT* schrob!
Das ist so wie winken – wank – gewunken
analog zu sinken – sank – gesunken
demnächst: blinken – blank – geblunken
SCRN ;-)
Besser kannst Du Deine Ahnungslosigkeit nicht demonstrieren: 0.1 (und damit auch 0.2) ist im Binärsystem nicht repräsentierbar, auch von keiner sog. , denn 2 und 5 sind (co-)prim!
Dummerweise gibt's den Standard ANSI/IEEE-854…
verschiedene Math-Libs umgehen das Problem simple indem sie beim Rechnen eben auf Floating Point verzichten, was je nach Rechnung verschieden kompliziert ist.
Ach mein guter Freund, deine tolle IEEE 854-1987 [DEPRECATED] wurde 2008 von der IEEE 754-2008 abgelöst.
Dafür müsste man allerdings mindestens einen B.Sc. in Computer Science haben von 2008, und keinen Doktor in EDV von Anno sowieso.
Nicht immer ist der höhere Akademische Grad auf dem Stand der Technik™ Sie sind ja zweifellos sehr intelligent.
Aber komm bitte lass es jetzt einfach, ich brauche deine verbalen Angriffe nicht. Ich erkenne ja das es dich sehr stört, dass ich Recht habe.
Zum Thema Airbag
Ein Airbag wird von einem Gasgenerator aufgeblasen, der typischerweise pyrotechnisch funktioniert. Im Fall eines Unfalls hast Du dann einen Sack vor Dir, der mit heißen Verbrennungsabgasen gefüllt ist.
Wenn der Hersteller bei der Abdichtung geschlampt hat, dann dringt über die Zeit Feuchtigkeit in den Gasgenerator ein. Man denke nur an die brutalen Temperaturschwankungen von denen man in einem Auto ausgehen muss.
Die eingedrungene Feuchtigkeit macht den Treibsatz wesentlich brisanter. Im Fall eines Unfalls kann das schlimmstenfalls dazu führen, dass sich der Gasgenerator in seine Einzelteile zerlegt und dass man anstelle des Airbags Schrapnelle vom Gasgenerator im Gesicht hat.
In diesem Zusammenhang hat es bereits Todesfälle gegeben, z.B. https://de.wikipedia.org/wiki/Takata_(Unternehmen).
mmh vielleicht doch blöd wenn damit die Statik einer Hängebrücke berchnet wurde….
Also wenn Austal2000 bzw. Austal ebenfalls davon betroffen ist, dann gute Nacht!
Die völlige Ahnungslosigkeit einiger Poster ist erschreckend!
0) Weierstrass et. al. haben schon vor mehr als 150 Jahren bewiesen, dass (nicht nur bzw. auch) transzendentale mathematische Funktionen wie Sinus, Cosinus etc. mit beliebiger Genauigkeit durch Polynome berechenbar sind.
1) die Intel-Coprozessoren rechne(te)n intern mit mehr als 64 Bit in der Mantisse (siehe , und Bit) sowie mit 17 Bit im Exponenten, also mindestens 85 Bit!
2) der 1985 verabschiedete Standard ANSI/IEEE-754 spezifiziert, dass konforme Implementationen die 4 Grundrechenarten sowie die Quadratwurzel runden , die bis auf's letzte Bit EXAKT!
3) die für die Berechnung trigonometrischer Funktionen (nicht nur) per Polynom notwendige Argumentreduktion ist seit 1983 (siehe Payne/Hanek oder Corbett) ebenfalls bis auf's letzte Bit EXAKT möglich.
4) seit dem letzten Jahrtausend gibt es mehrere unabhängig voneinander entwickelte Standardbibliotheken, die (nicht nur) trigonometrische Funktionen bis auf's letzte Bit runden.
https://skanthak.hier-im-netz.de/ieee-754.html#payne-hanek zeigt zwei einfache Implementierungen, die bis auf's vorletzte Bit korrekt sind.
Deine Kritik geht am Problem vorbei.
Es gibt hier 3 Probleme auf die, die meisten Poster aufspringen, und der Artikel geht nicht näher auf die Problemklasse ein.
– etwas verrechnet sich -> falsche Implementierung
das liegt nicht vor
– lineare Ungenauigkeit durch Rundung
das ist bei dem Bug das Problem, ein Fehler der in dem Fall mit größeren Zahlen "wächst". Das passiert normal durch ungünstiges Runden, wodurch sich Fehler vergrößern.
– Darstellung von Zahlen mit Base-10 und Base-2
Floating Point Zahlen sind intern als Basis-2 dargestellt. Und man kann für viele Menschen Überraschend Base-2 nicht immer verlustfrei auf Base-10 umrechnen.
(Binär Dezimal)
Z.b. die Zahl 0.2 wird wenn nach Basis-2 umgerechnet unendlich periodisch, wodurch 0.1+0.2 -> eben im Floating Point nicht genau 0.3 ergibt.
Wenn jemand diese Umrechnung genau braucht, z.b. für Finanzdaten dann muss er spezielle Mathematik Bibliotheken verwenden, welche das Problem umgehen.
Noch erschreckender ist allerdings, dass in den letzten 33 Jahren NIEMANDEM dieser trivial nachweisbare Fehler der Argumentreduktion von IBMs im Quellcode, also als veröffentlichter alias , die weniger als 96 statt mindestens 108 Bits verwendet, oder anderen Bibliotheken wie GNU libc, die ihn übernommen haben, aufgefallen ist!
Kommt immer auf die Anwendung an.
Ich habe mir den Chatverlauf jetzt nach einigen Tagen nach meinem Initial-Kommentar vom 25.07.2026 / 08:53 Uhr angeschaut und bin extrem negativ überrascht, wie hier einige Kommentatoren auf einander losgehen.
Voll-IT-Profi gegen Pseudo-IT-Profi o.ä. – Kompetenzgerangel @ it´s Best.
So stellt sich das für mich LEIDER dar.
Das war weder meine Absicht noch hilft es irgendjemanden.
Ist es denn wirklich SO SCHWER, einem Laien etwas kompliziertes an einem möglichst einfachen Beispiel darzulegen, gemäß dem Motto: "Wie erklär ich es meinem Kinde …"
Und wenn das für den einen oder anderen Kommentator (z.B. "Die völlige Ahnungslosigkeit einiger Poster ist erschreckend!") unter seinem Niveau ist, so möge er doch bitte schweigen.
Ich habe in meinem Erst-Beitrag eine simple Frage gestellt und einige mögliche Szenarien skizziert, die mir so eingefallen sind:
" Wie und wo genau kann sich solches massives "verrechnen" positiv, negativ oder gar nicht auswirken?
– Dimensionierung von (Atom-, Wasser-, Wind-) Kraftwerksanlagen?
– Dimensionierung von (Raketen-/Weltraum) Triebwerken?
– Flugbahnberechnungen?
– Dimensionierung von Waffen, Munition & Bomben o.ä.
– Wettervorhersage
– Simulation von Auswirkungen von z.B. Stürmen (Wind, elektromagnetisch), Erdbeben und Tsunamis
– ????
Das wären jetzt so die Punkte, die UNS ALLE bei massiver negativer Fehlerhaftigkeit betreffen könnte bzw. würde.
Danke schön."
Wäre schön, wenn dahingehend einige aussagekräftige und für Otto-Normalverbraucher verständliche Antworten kommen würden, ohne dass das ins ein Kompetenzgerangel und Beschimpfungen ausartet.
Ich bin kein IT-Profi, lese aber diesen Blog sehr gern.
Ich habe mir bereits viel von dem Wissen und von Erfahrungen der Artikel und Kommentatoren zu Nutze machen können und möchte an dieser Stelle Günter Born nochmals sehr danken, diesen Blog weiter zu betreiben.
Auch danke ich allen anderen Kommentatoren, die zielführende Antworten und auch auf ggf. "einfachen" Niveau posten, ohne Beschimpfungen und Kompetenzgerangel.
"Dort bescheinigen sie sie (fast) allen mathematischen Funktionen der GNU libm einen maximalen Fehler von 0.5 ULP bescheinigen."
@ GB: Die Kardinalität der Elemente und führt zu einer sprachlichen Normabweichung von 2 ULP (Units of Linguistic Precision) und liegt somit außerhalb des Toleranzbereichs von 0.5 ULP . .-)
PS: Es gibt offenbar Probleme beim Speichern der Kommentaränderung.
Nicht gespeichert wurde die Bezeichnung der Elemente "sie" und "bescheinigen".
Meine volle Zustimmung.
Hier im Blog sind ja überwiegend Kommentatoren versammelt, die wissen von was sie reden – nicht jeder muß ein Mathematikstudium abgeschlossen haben (gibt ja z.B. noch andere Studiengänge – mit der Aussage werde/will ich niemandem auf die Füße treten (deshalb auch das "z.B.").
Leider haben sich die Kontrahenten derart verbissen, dass sie die Ausgangsfrage aus den Augen verloren haben – ich gehe mal, zu ihren Gunsten, davon aus, dass sie sich nicht zu fein dafür sind.
Also muß man wieder selber rechnen ;-)
Wie man mal wieder sieht: Selber machen ist meistens das Beste.