Ce que nous devrions tous savoir

    1

2ulp(1) = ¹₂β1−p pour le mode d’arrondi au plus près,

ulp(1) = β^1−p pour les modes d’arrondis dirigés.

Remarque 2.1.1. La combinaison de ces deux phénomènes (élimination catastrophique et ab-sorption) peut tourner à la catastrophe. Par exemple en simple précision, si a = 1 et b = 2⁻³⁰ alors a + b = 1 ⇒ (a + b) − a = 0.

La propagation des erreurs est également un problème important. Une erreur commise sur un résultat res, peut entraîner une plus grande erreur quand le dernier résultat res est utilisé dans un nouveau calcul. Lorsque les erreurs du premier ordre sont très significatives, elles peuvent engendrer des erreurs de second ordre énormes.

Théoriquement, ces problèmes entraînent la perte des propriétés algébriques (par exemple la perte de l’associativité) et la perte de la notion d’ensemble continu (les réels sont approchés par un ensemble discret) et ont un impact important sur les résultats des algorithmes numé-riques. On peut également noter une perte de précision dans les calculs en arithmétique flot-tante (l’ordinateur ne fournit pas la valeur exacte mais une valeur approchée) et des problèmes de branchements conditionnels (le déroulement d’un programme dépend souvent de tests : Si

x < yalors . . . .... Sinon. . . , la réponse de ces tests peut varier en fonction de la propagation des erreurs d’arrondi).

Nous avons exposé dans cette section les grandes lignes et définit le vocabulaire de l’arith-métique à virgule flottante et de la norme IEEE 754. Les chapitre 2 et 3 de l’ouvrage de Jean-Michel Muller [Muller et al., 2010] présentent ces notions en profondeur. On peut aussi consul-ter plusieurs pages web dédiées à ce sujet :

– http://www.validlab.com/;

– http://www.eecs.berkeley.edu/~wkahan/;

– http://perso.ens-lyon.fr/jean-michel.muller/; – http://www.vinc17.org/research/index.fr.html.

2.1.4 Ce que nous devrions tous savoir

Certains évoquent à tort ou à raison le côté obscur de la simulation numérique. En effet, les problèmes numériques ne proviennent pas toujours des programmateurs mais aussi de l’ar-chitecture ou du langage de programmation utilisé. Nous nous proposons ici de faire un petit tour d’horizon des concepts (notions) que tout concepteur de logiciel de simulation numérique devrait absolument savoir.

2.1.4.1 Implémentation de l’arithmétique flottante

Nous avons montré dans la section précédente que l’arithmétique à virgule flottante repose sur la norme IEEE 754 qui exige un arrondi correct pour les quatre opérations élémentaires

2.1. Parce que l’ordinateur n’est pas obligé d’être juste

(+, −, ×, /) et la racine carrée. Dans ces conditions, qui est responsable de l’implémentation et du respect de la norme sur nos machines ? En effet, les résultats de l’exécution d’un code dépendent de l’environnement de travail (OS), de l’architecture matérielle sur laquelle est exécuté le code (le processeur), du langage de programmation (C, C++, Fortran), du compilateur utilisé (Intel, GNU GCC, etc) et du développeur qui a écrit le code.

Le processeur : il est le responsable de l’implémentation matérielle des opérations de base de l’arithmétique flottante grâce aux FPU (floating point unit) qui possèdent des registres internes dédiés aux flottants. Il signale les exceptions et s’occupe de l’écriture des résul-tats en mémoire. De manière générale, les architectures actuelles disposent d’implémen-tations matérielles pour l’addition, la soustraction, la multiplication, la division et racine carrée pour la simple et la double précision (cftableau 2.2) [Muller et al., 2010, section 3.5]. Sur ces architectures modernes, les opérations en arithmétique flottante sont confiées aux instructions SIMD (Single Instruction Multiple Data). Ce type d’instructions permet de réaliser en un cycle une même opération sur tous les éléments d’un vecteur. Il n’est pas superflu d’ajouter que suivant les architectures matérielles, la taille des registres internes des FPU est différente (64 bits, 96 bits, 128 bits). Cette différence de taille peut engen-drer des différences dans les résultats en fonction des ordinateurs. A ces instructions, on ajoutera les FMA (Fused Multiply-and-Add) disponibles sur presque toutes les architec-tures modernes (ARM, Power, PowerPC, IA64, GPU, processeurs Intel et AMD). Le FMA permet de faire en une seule opération une addition et une multiplication a × b + c avec un seul arrondi. Plus rapide et plus précis, il permet une meilleure implémentation de la racine carrée et de la division. Cependant, son utilisation dépend du compilateur. Par exemple, par défaut GCC désactive l’utilisation du FMA sauf pour l’addition et la multi-plication³⁰[De Dinechin, 2013]. Notons que l’utilisation des FMA a été standardisée dans la norme IEEE 754-2008.

Le système d’exploitation (OS) : l’OS s’occupe du traitement des exceptions signalées. C’est également lui qui est en charge du calcul des fonctions ou opérations non gérées par le processeur (par exemple les fonctions mathématiques sin, cos, log, etc, la racine carrée sur les architectures récentes). La gestion des nombres flottants incombe aussi à l’OS (préci-sion, choix du mode d’arrondi par défaut, nombres dénormalisés). Dans les récents FPU, le mode d’arrondi peut être géré directement par les instructions assembleurs.

Les Langages de programmation : ils respectent une sémantique d’interprétation bien précise expliquée dans leurs documents de référence. Chaque langage possède sa propre séman-tique. L’ordre d’évaluation d’une expression et la précision des résultats intermédiaires dépend du langage utilisé. Par exemple, les documents de référence du Fortran stipulent qu’il respecte uniquement les propriétés mathématiques. En revanche, le langage C im-pose un sens pour les évaluations et les résultats intermédiaires sont calculés avec la plus grande précision disponible sur l’architecture si les performances ne sont pas impactées. C’est la principale raison pour laquelle, il est conseillé d’utiliser des parenthèses pour obliger les langages à respecter l’ordre d’évaluation que l’on souhaite.

Le compilateur : chaque compilateur offre des centaines d’options de compilation et par dé-faut ces options servent prioritairement à l’optimisation en termes de vitesse d’exécution. Généralement, ces optimisations se font au dépend de la qualité numérique.

Finalement, "peu" de responsabilités reposent directement sur les développeurs. En effet, plu-sieurs choix ayant un impact considérable sur la qualité numérique des résultats sont faits à

Chapitre 2. La validation numérique : principes et méthodes

l’insu des développeurs. Nous voulons dans cette partie convaincre de l’importance des lan-gages et des compilateurs dans la reproductibilité des résultats de calcul. Il n’existe pas de solu-tion miracle pour avoir des résultats reproductibles, mais le développeur gagnerait beaucoup à porter attention à la documentation du langage qu’il utilise ainsi que des options de compi-lation auxquelles il fait appel. Nous avons présenté ici un survol de la compatibilité entre la norme IEEE 754 et son implémentation dans les ordinateurs. Ces aspects de la norme sont trai-tés en détail dans les chapitre 3 et 7 de [Muller et al., 2010]. Ce chapitre traite en particulier des spécificités des langages C, C++, Fortran et Java à propos duquel W. Kahan a écrit un article intitulé How Java’s floating-point hurts everyone everywhere [Kahan et al., 1998].

2.1.4.2 Les algorithmes critiques

Au delà des problèmes liés au respect de la norme, certains algorithmes de base utilisés dans les simulations numériques sont reconnus très instables numériquement. On citera en particulier la sommation, le produit scalaire et l’évaluation polynômiale. La qualité numérique des résultats de ces trois problèmes dépend directement du nombre de conditionnement des paramètres en entrée. En effet, le nombre de cancellations est proportionnel au nombre de conditionnement (introduit ensection 2.2.1). Rump a consacré une grande partie de ses travaux à l’obtention d’algorithmes de sommation qui minimisent l’effet des erreurs d’arrondi [Ogita et al., 2005,Rump, 2009]. Un nombre important d’ouvrages a été consacré à ce sujet dans la lit-térature [Malcolm, 1971,Demmel et Hida, 2004,Zhu et Hayes, 2010,Demmel et Nguyen, 2013]. La sommation est d’autant plus importante puisqu’à partir d’un algorithme de sommation précis, on obtient un algorithme de produit scalaire d’une meilleure précision, un meilleur al-gorithme pour le produit de matrices et les différents alal-gorithmes d’algèbre linéaire faisant appel au produit scalaire. En ce qui concerne les évaluations polynomiales, on peut se référer à la thèse [Louvet, 2007]. Ces travaux sont pour la plus part basés sur le concept d’algorithmes compensés que nous introduisons dans lasection 2.2et que nous mettons en pratique au cha-pitre 6. Le livre [Higham, 2002] est la référence à lire en ce qui concerne la stabilité numérique d’algorithmes d’algèbre linéaire.

2.2 L’ordinateur peut être source d’erreur... et alors ?

En se basant sur les notions exposées dans la section 2.1, il est évident qu’il est impos-sible d’éviter la propagation des erreurs d’arrondi dans les calculs flottants. Il faudrait sinon se passer de l’ordinateur et travailler uniquement sur des systèmes complètement fiables. En-core faudrait-il que de tels systèmes existent et si oui qu’ils soient capables de faire de grandes simulations complexes comme c’est le cas aujourd’hui [Muller et al., 2010, section 7.6]. Dans ce contexte, le mieux que l’on puisse faire est de borner l’erreur finale afin d’estimer la qua-lité numérique de notre résultat (section 2.2.1). L’analyse et la compréhension des effets de la propagation des erreurs d’arrondi permettent d’estimer plus précisément la qualité numérique des résultats d’un calcul à arithmétique flottante. Une autre solution envisageable pour limiter les conséquences de la propagation des erreurs d’arrondi est la mise en œuvre des techniques qui permettent d’améliorer la précision des résultats calculés (section 2.2.2). Outre l’analyse et l’amélioration de la précision, on peut aussi envisager de détecter les erreurs afin d’y proposer des solutions (section 2.2.3).

2.2. L’ordinateur peut être source d’erreur... et alors ?