Pourquoi l'exactitude du module en virgule flottante est-elle importante?

9

La plupart des dialectes Smalltalk implémentent actuellement un module flottant inexact naïf (fmod / reste).
Je viens de changer cela pour améliorer Squeak / Pharo et éventuellement d'autres adhérences Smalltalk aux normes (IEEE 754, ISO / IEC 10967), comme je l'ai déjà fait pour d'autres opérations en virgule flottante de pointe.

Cependant, pour l'adoption de ces changements, je m'attends à ce que le respect de la norme ne soit pas suffisant pour convaincre mes pairs, donc expliquer dans quelles circonstances cette exactitude importerait vraiment m'aiderait beaucoup. Je n'ai pas pu trouver un bon exemple par moi-même jusqu'à présent.

Est-ce que quelqu'un ici sait pourquoi / quand / où (IOW dans quel algorithme) une telle exactitude du module importerait?

arithmetic floating-point aka.nice
la source
Je pense que vous pourriez obtenir de meilleures réponses sur la science informatique, car ces questions sont plus importantes dans leur (sous-) domaine. Dans tous les cas, la question est ontopique ici et vous devriez donner à nos répondeurs quelques jours avant de republier.
Raphael
1
J'ai vu du code s'appuyant sur l'exactitude de fmod / modf qui m'a fait frémir, mais la possibilité qu'un langage ose implémenter un module naïf inexact en virgule flottante semble encore plus effrayant. Exemple de code: (1) Prenez le reste. (2) Arrêtez-vous s'il est nul. (3) Multipliez-le par 2 et passez à (1). On peut faire un travail utile au cours de ce processus, mais le point crucial est que la fin de ce processus repose sur l'exactitude du reste et l'exactitude de la multiplication par 2. Je ne sais pas si je devrais donner une réponse plus complète ici, car la science informatique semble plus appropriée pour cette question.
Thomas Klimpel
Une supposition: normaliser l'entrée d'une fonction trigonométrique.
Paul A. Clayton
@ThomasKlimpel Je suis intéressé si vous trouvez des références. Notez que le reste naïf est défini comme (x - ((y / x) tronqué * x)) avec IEEE arrondi aux opérations paires les plus proches, nous pouvons prouver que exactRem (x, y) == 0 => naiveRem (x, y) == 0. Le problème est le contraire - fausse division exacte positive - comme naiveRem (4.0,0.1) == 0,0 qui correspond malheureusement aux attentes naïves dans de nombreux cas!
aka.nice
@ PaulA.Clayton oui, pour le sinus en degrés peut-être ... Cependant, je suppose que le rem naïf fonctionne aussi bien que le rem exact jusqu'à env. 1e16 degrés parce que 360 ​​n'a qu'une plage de 6 bits définie, et parce que la division par 360 ne semble jamais arrondir pour les prédécesseurs de multiples de 360 ​​... Pour les radians, une bibliothèque décente nécessite une précision multiple, un rem exact limité à une double précision vraiment aider dans un tel cas?
aka.nice

Réponses:

1

Notez que la mise en œuvre inexacte en virgule flottante affecte la météo.

Il y a eu des tests exécutant des prévisions météorologiques avec les mêmes entrées sur un matériel différent et les prévisions ont divergé. Si vous utilisez un algorithme itératif, une petite différence d'arrondi ici ou là peut entraîner un effet papillon qui transforme le soleil en pluie.

Les règles d'arrondi dans les normes (IEEE 754, ISO / IEC 10967) ont été soigneusement pensées afin que les algorithmes numériques se comportent de manière prévisible avec la plus grande précision et reproduisent le même résultat à chaque fois. En ne suivant pas les algorithmes numériques standard conçus pour ces règles d'arrondi, les règles d'arrondi se briseront et les algorithmes itératifs comme les prévisions météorologiques peuvent même donner un résultat aléatoire.

(et cela ne dit-il pas quelque chose sur les prévisions météorologiques? :)

Goswin von Brederlow
la source
1
D'un autre côté, si l'effet papillon change le soleil en pluie, alors vos résultats n'étaient de toute façon pas utiles.
gnasher729
Il était une fois, j'ai enregistré des données flottantes en ASCII avec pas assez de chiffres. Un client voulait me montrer un problème, mais après avoir restauré les données du fichier ASCII, le problème a disparu. J'ai dit que quelques ulp off ne devraient pas avoir d'importance, si son problème était mal conditionné, je ne pouvais rien faire de toute façon. Il a dit que c'était son affaire, la mienne était de fournir un logiciel permettant la reproductibilité de ses propres problèmes. Il avait raison.
aka.nice
C'est pourquoi vous devez générer des nombres à virgule flottante pour les sauvegardes sous forme hexadécimale à l'aide de% a.
Goswin von Brederlow