Genau dafür hat die FPU extra ein Flag, Bit 5 im SR. Über das C1 Flag teilt sie i.d.R. zusätzlich mit ob auf- oder abgerundet wurde. Man entdeckt sehr wohl und leicht dass das Ergebnis fehlerbehaftet ist.
Die Größenordnung des Fehlers muss man immernoch selbst bestimmen, und vorallem dann eine alternative Rechenmethode ausführen, die es genauer macht.
Welche Methode man auswählen muss hängt dann immer noch von den konkreten Werten ab die verrechnet werden sollen, z.B. ob es Integerwerte sind oder sie dazu verlustfrei skaliert werden könnten, um dann korrekt zu rechnen.
Abgesehen davon verwenden sie aber nicht die FPU, SSE oder ähnliches, sondern eine BigNum-Bibliothek die Dezimalzahlen darstellen kann.
Ist natürlich alles machbar, aber Aufwand, und nicht trivial.
Auch wenn man anstatt die antiquierte FPU zu verwenden bessere/genauere/modernere Rechenmethoden programmiert ist das keine Entschuldigung dafür bei derart trivialen Aufgaben ein falsches Ergebnis zu liefern. Die Erkennung von Fehlern bei Fließkommaoperationen war schon vor 30 und mehr Jahren möglich.
BigNum-Bibliothek die Dezimalgleitkomma unterstützten gibt es sicherlich nicht seit 30 Jahren. Die FPUs haben sich erst Mitte der 80er stabilisiert, und ein großer Teil der Numerik entwickelt sich immernoch.
edit: Weiters geht es hier in den genannten Beispielen von 2-sqrt(4) und 2.5-sqrt(6.25) um Rechnungen bei denen niemals eine Zahl auftritt die man nicht selbst als float exakt darstellen kann. Dabei nicht exakt 0 als Ergebnis zu liefern kann nicht über finite Präzision der Datentypen erklärt werden.
Binary floats und ihre Implementierung sind aber nicht relevant, da sie nicht verwendet werden, um z.B. 0.1 rundungsfrei darstellen zu können.
Es bleibt dass andere Rechnungen ebenso betrachtet werden müssen, sonst kriegt man irgendwo ungefähr 4 raus, und die Wurzel davon ist wieder nicht 2.
Faszinierend. Man braucht eigentlich garnichts weiter zu machen als diese Berechnung genau so in eine herkömmliche x87 FPU zu hämmern um ein richtiges und exaktes Ergebnis zu erhalten, gerade eben versucht.
Siehe oben. Das bringt nichts, da der Windows-Rechner Dezimalbrüche rundungsfrei speichert, und daher binary floats nicht verwenden kann.
Versuche mal sqrt(4) + 0.1, das Ergebnis ist nicht wie erwartet 2.1, da gar nicht darstellbar.
Und ein normaler Taschenrechner sollte wenn, dann auch sowas richtig rechnen.
Ups, doch nicht so einfach...
Mich stört auch das Prinzip "gibt es schon irgendwo seit langem, ist doch selbstverständlich dass ihr das auch habt". Wenn man es oberflächlich betrachtet, ja. Im Detail passt das dann aber nicht mehr, siehe DecimalFloats.
Die wurden für Hardware erst 2008 standardisiert, und von Implementierungen ist bisher nicht viel zu sehen.
.
Ich möchte mich dann anders ausdrücken..
