Warum ist die Genauigkeit des Gleitkommamoduls wichtig?

Die meisten Smalltalk-Dialekte implementieren derzeit einen naiven ungenauen schwebenden Modul (fmod / rest).
Ich habe dies nur geändert, um die Einhaltung von Squeak / Pharo und eventuell anderen Smalltalk-Standards (IEEE 754, ISO / IEC 10967) zu verbessern, wie ich es bereits für andere Gleitkommaoperationen nach dem Stand der Technik getan habe.

Für die Übernahme dieser Änderungen gehe ich jedoch davon aus, dass die Einhaltung von Standards nicht ausreicht, um meine Kollegen zu überzeugen. Daher würde es mir sehr helfen, zu erklären, unter welchen Umständen diese Genauigkeit wirklich wichtig wäre. Ich konnte bisher selbst kein gutes Beispiel finden.

Weiß hier jemand, warum / wann / wo (IOW in welchem Algorithmus) eine solche Genauigkeit des Moduls von Bedeutung ist?

arithmetic floating-point

— aka.nice
quelle

Ich denke, Sie erhalten möglicherweise bessere Antworten auf Computational Science, da solche Probleme in ihrem (Unter-) Bereich wichtiger sind. In jedem Fall ist die Frage hier ontopisch und Sie sollten unseren Antwortenden einige Tage vor dem erneuten Posten geben.

— Raphael

Ich habe Code gesehen, der sich auf die Genauigkeit von fmod / modf stützt, was mich erschaudern ließ, aber die Möglichkeit, dass eine Sprache es wagt, einen naiven ungenauen Gleitkommamodul zu implementieren, scheint noch beängstigender. Beispielcode: (1) Nehmen Sie den Rest. (2) Stoppen Sie, wenn es Null ist. (3) Multiplizieren Sie es mit 2 und gehen Sie zu (1). Während dieses Prozesses kann man einige nützliche Arbeiten ausführen, aber der entscheidende Punkt ist, dass die Beendigung dieses Prozesses von der Genauigkeit des Restes und der Genauigkeit der Multiplikation mit 2 abhängt. Ich bin mir nicht sicher, ob ich hier eine vollständigere Antwort geben soll, da Computational Science angemessener erscheint für diese Frage.

— Thomas Klimpel

Eine Vermutung: Normalisierung der Eingabe einer trigonometrischen Funktion.

— Paul A. Clayton

@ThomasKlimpel Ich bin interessiert, wenn Sie Referenzen finden. Beachten Sie, dass der naive Rest definiert ist als (x - ((y / x) abgeschnitten * x)), wobei IEEE auf die nächsten geraden Operationen gerundet ist. Wir können beweisen, dass exaktes Rem (x, y) == 0 => naives Rem (x, y) == 0. Das Problem ist das Gegenteil - falsch exakte Division positiv - wie naiveRem (4.0,0.1) == 0.0, was leider in vielen Fällen den naiven Erwartungen entspricht!

— aka.nice

@ PaulA.Clayton ja, für Sinus in Grad vielleicht ... Obwohl ich vermute, dass naive Rem genauso gut funktioniert wie exakte Rem bis zu ca. 1e16 Grad, weil 360 nur einen Bereich von 6 Bits gesetzt hat und weil die Division durch 360 für Vorgänger von Vielfachen von 360 niemals aufzurunden scheint ... Für Bogenmaß erfordert eine anständige Bibliothek eine Mehrfachgenauigkeit, eine exakte Rem ist auf doppelte Genauigkeit beschränkt wirklich helfen in einem solchen Fall?

— aka.nice

Beachten Sie, dass eine ungenaue Gleitkommaimplementierung das Wetter beeinflusst.

Es wurden Tests durchgeführt, bei denen Wettervorhersagen mit denselben Eingaben auf unterschiedlicher Hardware ausgeführt wurden, und die Vorhersagen gingen auseinander. Wenn Sie einen iterativen Algorithmus ausführen, kann ein kleiner Rundungsunterschied hier oder da dazu führen, dass ein Schmetterlingseffekt Sonnenschein in Regen verwandelt.

Die Rundungsregeln in Normen (IEEE 754, ISO / IEC 10967) wurden sorgfältig durchdacht, damit sich numerische Algorithmen mit höchster Genauigkeit vorhersehbar verhalten und jedes Mal das gleiche Ergebnis reproduzieren. Wenn Sie die für diese Rundungsregeln entwickelten numerischen Standardalgorithmen nicht befolgen, werden sie gebrochen, und iterative Algorithmen wie Wettervorhersagen können sogar zu einem zufälligen Ergebnis führen.

(Und sagt das nicht etwas über Wettervorhersagen aus? :)

— Goswin von Brederlow
quelle

Wenn andererseits der Schmetterlingseffekt Sonnenschein in Regen verwandelt, waren Ihre Ergebnisse ohnehin nicht nützlich.

— Gnasher729

Es war einmal, ich habe Float-Daten in ASCII mit nicht genügend Ziffern gespeichert. Ein Client wollte mir ein Problem zeigen, aber nach dem Wiederherstellen der Daten aus der ASCII-Datei verschwand das Problem. Ich sagte, dass ein paar ulp off keine Rolle spielen sollten, wenn sein Problem schlecht konditioniert war, gibt es sowieso nichts, was ich tun könnte. Er sagte, es sei seine Sache, meine sei es, Software bereitzustellen, die die Reproduzierbarkeit seiner eigenen Probleme ermöglicht. Er hatte recht.

— aka.nice

Aus diesem Grund sollten Sie Gleitkommazahlen zum Speichern als Hexadezimalzahlen mit% a ausgeben.

— Goswin von Brederlow