IEEE 754

IEEE 754 est la norme pour l’arithmétique en virgule flottante, publiée pour la première fois en 1985 et mise à jour en 2008 et 2019. Elle définit les formats binaires et décimaux en virgule flottante, le comportement d’arrondi, la gestion des exceptions et les valeurs spéciales (NaN, ±Infinity, −0).

Le format double précision standard est ce qu’utilisent les Numbers JavaScript, les flottants Python et la plupart des types “nombre” dans les langages modernes :

• 64 bits au total
• 1 bit de signe
• 11 bits d’exposant
• 52 bits de mantisse
• ~15-17 chiffres décimaux significatifs de précision
• Plage approximative de 4,9e−324 à 1,8e+308

L’exemple célèbre : 0.1 + 0.2 === 0.3 retourne false dans presque tous les langages. La raison : 0,1 et 0,2 n’ont pas de représentation binaire exacte (tout comme 1/3 n’a pas de représentation décimale exacte). Leurs valeurs stockées sont très proches de, mais pas exactement 0,1 et 0,2, et l’addition amplifie l’infime erreur. Le résultat est 0,30000000000000004.

Implications pour nos outils : la plupart des conversions sont précises à ~15 chiffres décimaux, ce qui est plus que toute entrée que nous acceptons. Là où cela importe : les montants en cryptomonnaies, où 18 décimales de Wei dépassent la plage de Number — nous utilisons BigInt pour conserver une précision exacte.

Exemple concret

Considérez le calcul 0.1 + 0.2 en JavaScript. Le littéral 0,1 en binaire IEEE 754 est en réalité 0,10000000000000000555111512312578… (le double représentable le plus proche). 0,2 est 0,20000000000000001110223024625157…. Les additionner et arrondir au double représentable le plus proche donne 0,30000000000000004440892098500626…, affiché comme 0.30000000000000004. La vraie réponse mathématique 0,3 n’est pas représentable exactement en binaire — sa représentation est aussi approximativement 0,299999…9989…. L’erreur est dans le dernier ulp (unité en dernière position), environ 1 sur 10¹⁶. Pour les nombres visibles c’est invisible ; pour des sommes de millions de petites valeurs, elle s’accumule : sommer 0,1 cent fois dans une boucle et comparer à 10,0 retournera false. Utilisez la sommation de Kahan ou la sommation compensée lorsque la précision importe dans de longues accumulations.

Deux autres pièges liés aux valeurs spéciales méritent d’être connus : les nombres sous-normaux (valeurs très petites proches de zéro avec une précision réduite) échangent la plage représentable contre un débordement inférieur gracieux, et les NaN signalants (sNaN) peuvent être utilisés pour détecter une mémoire non initialisée, bien que la plupart des langages ramènent tous les NaN à des NaN silencieux (qNaN) sans jamais exposer cette distinction au code utilisateur.

Quand et pourquoi c’est important

IEEE 754 importe chaque fois que du code compare des flottants par égalité, additionne de nombreuses petites valeurs, ou traite des valeurs proches des limites du format. Le bug financier classique consiste à calculer “total = total + 0,01” dans une boucle un million de fois et à découvrir que le résultat est légèrement décalé au point d’échouer à une réconciliation de bilan. La solution est de ne jamais utiliser des flottants pour l’argent — utilisez BigDecimal, decimal.Decimal de Python, decimal.js de JavaScript, ou stockez les montants sous forme d’entiers (centimes plutôt que dollars, satoshis plutôt que bitcoin, wei plutôt qu’ETH). L’autre bug classique est la cancellation catastrophique qui se produit lors de la soustraction de deux flottants quasi-égaux — les chiffres significatifs de tête s’annulent, ne laissant que le bruit dans les bits inférieurs. Les manuels d’analyse numérique consacrent des chapitres entiers aux algorithmes qui évitent ce piège. Référence : Goldberg D. — Ce que tout informaticien devrait savoir sur l’arithmétique en virgule flottante.

Les cinq valeurs spéciales que tout le monde oublie : IEEE 754 définit +0 et −0 comme distincts (ils se comparent égaux mais produisent des résultats différents en division — 1/+0 est +∞ tandis que 1/−0 est −∞), +Infinity et −Infinity pour les dépassements, et NaN (Not a Number) pour les opérations indéfinies comme 0/0 ou √−1. NaN est fameux pour n’être pas égal à lui-même — NaN === NaN est false — ce qui est la façon dont IEEE 754 propage les erreurs à travers les calculs plutôt que de les masquer. La vérification Number.isNaN() existe dans chaque langage moderne précisément parce que le test d’égalité évident ne fonctionne pas.

Quand vous avez vraiment besoin de décimal exact — et quoi utiliser à la place : pour l’argent, ne jamais utiliser des flottants. BigDecimal de Java, decimal.Decimal de Python, des bibliothèques JavaScript comme decimal.js, et le type NUMERIC de PostgreSQL implémentent tous l’arithmétique décimale exacte. Le coût est d’environ 10 à 100 fois plus lent que les opérations flottantes natives, ce qui convient parfaitement à tout système de transactions côté utilisateur. Pour le calcul scientifique où le comportement d’arrondi importe, l’arrondi au plus proche pair (arrondi du banquier) d’IEEE 754 est ce qui produit des sommes accumulées stables. Référence : IEEE 754-2019 — Arithmétique en virgule flottante.