scientificware / jdk

Read-only mirror of https://hg.openjdk.java.net/jdk/jdk
GNU General Public License v2.0
0 stars 0 forks source link

JDK and Numbers IEEE 754, BigDecimal, ... #20

Open scientificware opened 1 year ago

scientificware commented 1 year ago

Oracle® Developer Studio 12.6: Numerical Computation Guide

Les remarques précédentes ne visent pas à dénigrer les systèmes à base étendue mais à exposer plusieurs erreurs, la première étant que tous les systèmes IEEE 754 doivent fournir des résultats identiques pour le même programme. Nous nous sommes concentrés sur les différences entre les systèmes à base étendue et les systèmes simples/doubles, mais il existe d'autres différences entre les systèmes au sein de chacune de ces familles. Par exemple, certains systèmes simples/doubles fournissent une seule instruction pour multiplier deux nombres et en ajouter un troisième avec un seul arrondi final. Cette opération, appelée multiplication-addition fusionnée, peut amener le même programme à produire des résultats différents sur différents systèmes simples/doubles, et, comme la précision étendue, elle peut même amener le même programme à produire des résultats différents sur le même système selon que et quand il est utilisé. Une multiplication-addition fusionnée peut également déjouer le processus de division du théorème 6, bien qu'elle puisse être utilisée de manière non portable pour effectuer une multiplication de précision multiple sans avoir besoin de division. Même si la norme IEEE ne prévoyait pas une telle opération, elle s'y conforme néanmoins : le produit intermédiaire est livré à une "destination" indépendante de la volonté de l'utilisateur et suffisamment large pour le contenir exactement, et la somme finale est arrondie correctement pour correspondre à son destination simple ou double précision. L'idée que l'IEEE 754 prescrit précisément le résultat qu'un programme donné doit fournir est néanmoins séduisante. De nombreux programmeurs aiment croire qu'ils peuvent comprendre le comportement d'un programme et prouver qu'il fonctionnera correctement sans référence au compilateur qui le compile ou à l'ordinateur qui l'exécute. À bien des égards, soutenir cette conviction est un objectif louable pour les concepteurs de systèmes informatiques et de langages de programmation. Malheureusement, lorsqu'il s'agit d'arithmétique à virgule flottante, l'objectif est pratiquement impossible à atteindre. Les auteurs des normes IEEE le savaient et ils n'ont pas tenté d'y parvenir. Par conséquent, malgré une conformité presque universelle à la plupart des normes IEEE 754 dans l'ensemble de l'industrie informatique, les programmeurs de logiciels portables doivent continuer à faire face à une arithmétique à virgule flottante imprévisible. Si les programmeurs veulent exploiter les fonctionnalités de l'IEEE 754, ils auront besoin de langages de programmation qui rendent l'arithmétique à virgule flottante prévisible. La norme C99 améliore la prévisibilité dans une certaine mesure au détriment de l'obligation pour les programmeurs d'écrire plusieurs versions de leurs programmes, une pour chaque FLT_EVAL_METHOD. Il reste à voir si les futurs langages choisiront plutôt de permettre aux programmeurs d'écrire un programme unique avec une syntaxe qui exprime sans ambiguïté dans quelle mesure il dépend de la sémantique IEEE 754. Les systèmes étendus existants menacent cette perspective en nous incitant à supposer que le compilateur et le matériel savent mieux que le programmeur comment un calcul doit être effectué sur un système donné. Cette hypothèse est le deuxième sophisme : la précision requise dans un résultat calculé ne dépend pas de la machine qui le produit mais seulement des conclusions qui en seront tirées, et du programmeur, du compilateur et du matériel, au mieux seulement du programmeur peut savoir quelles peuvent être ces conclusions.