Exercices corrigés : représentation des données, réels et texte (NSI Première)

$101{,}101_{2}=4+0+1+\dfrac{1}{2}+0+\dfrac{1}{8}=5+0{,}5+0{,}125=5{,}625$. On additionne simplement les poids des positions où le bit vaut 1.

$0{,}625\times 2=1{,}25$, on note $1$ et il reste $0{,}25$. $0{,}25\times 2=0{,}5$, on note $0$ et il reste $0{,}5$. $0{,}5\times 2=1{,}0$, on note $1$ et il reste $0$. Le processus s'arrête : $0{,}625=0{,}101_{2}$.

$0{,}1\times 2=0{,}2$, on note $0$. $0{,}2\times 2=0{,}4$, on note $0$. $0{,}4\times 2=0{,}8$, on note $0$. $0{,}8\times 2=1{,}6$, on note $1$, reste $0{,}6$. $0{,}6\times 2=1{,}2$, on note $1$, reste $0{,}2$. On retrouve $0{,}2$, déjà rencontré : le processus BOUCLE. L'écriture est $0{,}0\overline{0011}_{2}$, périodique et infinie.

Ce sont exactement les nombres dont le dénominateur, une fois la fraction réduite, est une PUISSANCE DE 2. C'est le cas de $0{,}625=\dfrac{5}{8}$, de $0{,}5$ ou de $0{,}75$ ; ce n'est pas le cas de $0{,}1=\dfrac{1}{10}$, dont le dénominateur contient un facteur 5.

C'est une propriété du COUPLE nombre-base, pas un défaut d'un système. En base 10, une fraction s'écrit exactement si son dénominateur ne contient que des facteurs 2 et 5 ; en base 2, seulement des facteurs 2. Ainsi $\dfrac{1}{3}$ échoue dans les deux bases, tandis que $\dfrac{1}{10}$ passe en décimal et échoue en binaire. C'est de là que viennent toutes les surprises numériques des langages de programmation.

L'exposant sur $11$ bits code $2^{11}=2\,048$ valeurs. La mantisse sur $52$ bits en code $2^{52}\approx 4{,}5\times 10^{15}$.

Le total est de l'ordre de $2^{64}\approx 1{,}8\times 10^{19}$ valeurs, un peu moins en réalité car certaines combinaisons sont réservées. C'est un nombre FINI, alors que les réels sont en quantité infinie et même non dénombrable : la quasi-totalité des réels n'est donc pas représentable, et tout calcul flottant est un calcul approché.

La mantisse distingue environ $8{,}4\times 10^{6}$ valeurs par octave, ce qui correspond à un peu moins de $7$ chiffres décimaux, puisque $10^{7}=10\,000\,000$ est du même ordre. On retient donc environ $7$ chiffres significatifs en simple précision, et environ $16$ en double précision.

Parce que l'écriture est $m\times 2^{e}$ : à mantisse fixée, changer d'exposant multiplie l'ÉCART entre deux flottants voisins. Sur $[1;2]$, l'exposant vaut $0$ et il y a $2^{52}$ valeurs ; sur $[2;4]$, deux fois plus long, l'exposant vaut $1$ et il y a exactement le MÊME nombre de valeurs, donc des écarts deux fois plus grands. Les flottants sont serrés près de zéro et de plus en plus espacés en s'éloignant.

Trop grand : c'est le DÉPASSEMENT par le haut, et le résultat devient $\mathrm{inf}$, l'infini flottant, qui contamine ensuite tous les calculs. Trop petit : c'est le dépassement par le bas, et le résultat est arrondi à $0$, ce qui est plus insidieux car aucune alerte n'est levée et une division ultérieure produira une erreur inexpliquée.

Ni $0{,}1$ ni $0{,}2$ ne sont représentables exactement : la machine utilise pour chacun le flottant le plus proche, très légèrement différent. La somme de ces deux approximations n'est pas non plus représentable, et le flottant le plus proche de cette somme n'est pas celui qui représente $0{,}3$. L'écart apparaît à la limite des $16$ chiffres significatifs de la double précision, c'est-à-dire à la dix-septième décimale.

Elle renvoie $\mathrm{False}$. Tester l'égalité de deux flottants revient à exiger que deux chaînes d'arrondis distinctes aient produit exactement le même motif de $64$ bits, ce qui n'a aucune raison d'arriver. Le test réussit parfois, échoue parfois, et c'est justement ce caractère imprévisible qui en fait un bug redoutable.

On écrit $\mathrm{abs}(a-b)<10^{-9}$ plutôt que $a==b$. En pratique on préfère une tolérance RELATIVE, $\mathrm{abs}(a-b)\le tol\times \max(\mathrm{abs}(a),\mathrm{abs}(b))$, car une tolérance absolue de $10^{-9}$ n'a aucun sens pour des nombres de l'ordre de $10^{15}$.

Le résultat vaut exactement $1{,}0$. L'écart relatif entre les deux nombres, $10^{-20}$, est très inférieur à la précision relative de la double précision, environ $10^{-16}$ : le petit nombre disparaît entièrement dans l'arrondi. Ce phénomène s'appelle l'ABSORPTION.

Non : la boucle donne environ $100\,000{,}000\,001\,3$, un excès d'environ $1{,}3\times 10^{-6}$. L'approximation de $0{,}1$ n'y est presque pour rien : elle dépasse $0{,}1$ d'environ $5{,}6\times 10^{-18}$, ce qui, multiplié par un million, ne fait que $5{,}6\times 10^{-12}$. L'écart vient des arrondis des ADDITIONS : chaque somme partielle doit être ramenée au flottant le plus proche, avec une erreur d'autant plus grande que la somme est grande. Ces arrondis changent de signe, par excès à la troisième addition, par défaut aux huit suivantes, puis tantôt dans un sens, tantôt dans l'autre, et ils ne se compensent pas : leur bilan l'emporte de très loin sur l'erreur de départ. L'écart final se lit sur les derniers chiffres significatifs, et c'est exactement pour cela qu'un logiciel de comptabilité ne stocke jamais des euros en flottants, mais des centimes en entiers.

Les lettres se suivent dans l'ordre alphabétique : $C$ est la troisième lettre, donc $65+2=67$. De même $c$ vaut $97+2=99$. Le chiffre $5$ vaut $48+5=53$. On ne mémorise que les points de départ, jamais la table entière.

Il suffit d'AJOUTER $32$, puisque $97-65=32$. L'écart est le même pour toutes les lettres, ce qui n'est pas un hasard : $32=2^{5}$, si bien que passer d'une casse à l'autre revient à basculer un seul bit, le sixième.

$65=64+1=2^{6}+2^{0}$, donc $65=01000001_{2}$. En hexadécimal, on regroupe par quartets : $0100$ vaut $4$ et $0001$ vaut $1$, d'où $65=41_{16}$, noté $\mathrm{0x41}$.

Sur $7$ bits, $2^{7}=128$ caractères. C'est insuffisant dès qu'on quitte l'anglais : il n'y a de place ni pour les lettres accentuées du français, ni pour le $\beta$ allemand, ni pour les alphabets cyrillique, grec, arabe, encore moins pour les milliers d'idéogrammes chinois.

$N$ vaut $65+13=78$, $S$ vaut $65+18=83$, $I$ vaut $65+8=73$, et le retour à la ligne vaut $10$. La suite est donc $78$, $83$, $73$, $10$. Chaque code tenant sur un octet, le fichier pèse $4$ octets.

Un seul octet. Son point de code, $\mathrm{0x41}=65$, est inférieur à $128$ : il appartient à la plage compatible ASCII, codée sur un octet dont le premier bit vaut $0$. C'est la propriété de compatibilité ascendante qui a fait le succès d'UTF-8, tout fichier ASCII est déjà un fichier UTF-8 valide.

Non, il ne peut pas tenir sur un octet UTF-8 : $233$ dépasse $127$, et un octet dont le premier bit vaut $1$ est réservé aux séquences multi-octets. Il lui faut DEUX octets, $\mathrm{0xC3}$ puis $\mathrm{0xA9}$.

Ils indiquent la STRUCTURE de la séquence : un octet commençant par $110$ annonce un caractère sur deux octets, et tout octet commençant par $10$ est un octet de continuation. Un programme peut donc, en lisant un octet quelconque au milieu d'un fichier, savoir immédiatement s'il est au début d'un caractère ou au milieu, et se resynchroniser sans revenir au début. C'est ce qu'on appelle l'auto-synchronisation.

Les $3\,600$ caractères non accentués font $3\,600$ octets. Les $400$ accentués font $400\times 2=800$ octets. Les $80$ retours à la ligne font $80$ octets. Total : $3600+800+80=4\,480$ octets, soit environ $4{,}4\ \mathrm{kio}$, pour $4\,080$ caractères.

Le nombre de caractères est le nombre de symboles perçus par un lecteur humain ; le nombre d'octets est la place réellement occupée en mémoire, qui dépend de l'encodage choisi. En Python 3, $\mathrm{len}$ appliquée à une chaîne renvoie le nombre de CARACTÈRES ; pour obtenir les octets, il faut d'abord encoder la chaîne, par exemple avec la méthode d'encodage en UTF-8.

Parce que $0{,}1$ n'est pas représentable exactement : la variable $x$ ne prend jamais la valeur exacte $1{,}0$. Après dix additions elle vaut $0{,}9999999999999999$, un flottant très proche de $1$ mais différent de lui. Le test d'égalité échoue donc, et la boucle continue indéfiniment.

La garde s'active quand $n$ dépasse $20$, donc au vingt et unième tour. La variable $x$ vaut alors environ $2{,}1$, avec les dernières décimales polluées par les arrondis cumulés : le programme est déjà passé deux fois au-delà de la cible sans jamais l'atteindre.

On écrit $\mathrm{while}\ x<1{,}0$. La boucle s'arrête bien, mais le problème n'est pas totalement résolu : selon le sens des arrondis, elle peut faire dix ou onze tours, et l'on ne sait pas lequel sans exécuter le programme. Le comportement reste dépendant de la représentation machine.

On écrit une boucle sur un entier, par exemple pour $k$ allant de $0$ à $9$, et l'on pose $x=k/10$ à l'intérieur. Cette version est la bonne parce que le compteur est un ENTIER, représenté exactement : le nombre de tours est garanti, connu à la lecture, et les erreurs d'arrondi n'affectent plus que la valeur de $x$, jamais le déroulement du programme.

La règle est simple : on ne pilote JAMAIS une boucle avec un flottant. La variable de contrôle doit être un entier, et les valeurs réelles se calculent à partir de cet entier. Corollaire, on ne teste jamais l'égalité de deux flottants, on compare toujours à une tolérance près.

Le caractère accentué est stocké sur DEUX octets, $\mathrm{0xC3}$ et $\mathrm{0xA9}$. Le lecteur Latin-1 ignore la notion de séquence multi-octets : il traite chaque octet isolément et le convertit en un caractère. Il affiche donc le caractère de $\mathrm{0xC3}$, puis celui de $\mathrm{0xA9}$, soit deux symboles là où il n'y avait qu'une lettre.

Le mot compte $4$ caractères non accentués, à un octet chacun, et $2$ caractères accentués, à deux octets chacun : $4+4=8$ octets. Le lecteur Latin-1 croit lire $8$ caractères au lieu de $6$.

Le lecteur Latin-1 annonce autant de caractères que d'octets, soit $4\,480$. C'est $400$ de plus que les $4\,080$ caractères réels, exactement le nombre de caractères accentués du document, chacun ayant été compté deux fois.

Le décodage UTF-8 ÉCHOUE, car les octets isolés supérieurs à $127$ ne forment pas des séquences valides : le programme lève une erreur au lieu d'afficher n'importe quoi. L'erreur est donc plus visible, et paradoxalement plus facile à corriger : un plantage franc vaut mieux qu'un texte silencieusement abîmé, que l'on risque de réenregistrer tel quel et de perdre définitivement.

Premièrement, TOUJOURS spécifier l'encodage explicitement à l'ouverture d'un fichier, plutôt que de se fier à la valeur par défaut du système, qui diffère d'une machine à l'autre. Deuxièmement, choisir UTF-8 partout, à l'écriture comme à la lecture, et le déclarer dans les en-têtes des formats qui le permettent, comme les pages web.

FAUX. La double précision garantit environ $16$ chiffres SIGNIFICATIFS, ce qui n'est pas la même chose qu'un nombre de décimales exactes, et surtout $0{,}1$ et $0{,}2$ ne sont pas représentables exactement en binaire. Leur somme vaut $0{,}30000000000000004$ et diffère de $0{,}3$.

FAUX. Unicode est un RÉPERTOIRE : il attribue un numéro, le point de code, à chaque caractère, sans dire comment le stocker. C'est l'encodage, UTF-8, UTF-16 ou UTF-32, qui décide de la mise en octets.

FAUX. UTF-8 est un codage à longueur VARIABLE, de $1$ à $4$ octets selon le caractère. Les $128$ premiers points de code, ceux d'ASCII, tiennent sur un seul octet, les lettres accentuées sur deux, la plupart des idéogrammes sur trois.

FAUX. L'écart entre deux flottants consécutifs DOUBLE à chaque puissance de deux : ils sont très serrés près de zéro et de plus en plus espacés vers les grandes valeurs. C'est la conséquence directe de l'écriture $m\times 2^{e}$.

FAUX. La fonction de longueur renvoie un nombre de CARACTÈRES, alors que la taille du fichier se compte en OCTETS. Les deux ne coïncident que si tous les caractères sont codés sur un octet, c'est-à-dire pour un texte purement ASCII, sans le moindre accent.

Elle traite les cas où les deux valeurs sont rigoureusement identiques, ce qui arrive souvent en pratique. Surtout, elle règle le cas particulier de deux zéros : l'échelle valant alors $0$, la tolérance relative serait nulle et le test suivant échouerait à reconnaître que $0$ est égal à $0$.

Parce que la précision d'un flottant est elle-même RELATIVE : environ $16$ chiffres significatifs, quel que soit l'ordre de grandeur. Une tolérance absolue de $10^{-9}$ est absurde pour deux nombres de l'ordre de $10^{15}$, où l'écart entre deux flottants consécutifs dépasse déjà $1$ : le test échouerait toujours, même pour des valeurs voisines. Elle est tout aussi absurde pour des nombres de l'ordre de $10^{-20}$, où elle déclarerait égaux des nombres différant d'un facteur mille.

L'échelle vaut $\max(0, 10^{-20})=10^{-20}$, et la tolérance $10^{-9}\times 10^{-20}=10^{-29}$. L'écart $10^{-20}$ lui est très supérieur, donc la fonction renvoie faux. Ce n'est pas le comportement souhaité : à l'échelle d'un calcul ordinaire, $10^{-20}$ est indiscernable de zéro, et il faudrait les déclarer égaux.

On ajoute un plancher absolu : renvoyer vrai si $\mathrm{abs}(a-b)\le \max(tol_{abs},\ tol_{rel}\times \max(\mathrm{abs}(a),\mathrm{abs}(b)))$, avec par exemple $tol_{abs}=10^{-12}$. Le plancher prend le relais près de zéro, la tolérance relative gouverne partout ailleurs. C'est exactement la stratégie de la fonction de comparaison approchée de la bibliothèque standard.

Non, elle n'est PAS transitive. Avec une tolérance de $0{,}1$ en absolu, $1{,}00$ est proche de $1{,}09$ et $1{,}09$ est proche de $1{,}18$, alors que $1{,}00$ et $1{,}18$ diffèrent de $0{,}18$. La proximité approchée n'est donc pas une relation d'équivalence, et l'on ne peut pas s'en servir pour regrouper des valeurs ni pour trier. Elle sert à valider un résultat de calcul, rien de plus.

Elle pose que les INSTRUCTIONS et les DONNÉES sont stockées dans la même mémoire, sous la même forme binaire. Une même suite de bits peut donc être lue comme un nombre ou comme une instruction selon le contexte : c'est ce qui rend un ordinateur programmable, et c'est aussi ce qui rend indispensable de savoir toujours quel TYPE on manipule.

Parce que le huitième bit servait au CONTRÔLE DE PARITÉ, un mécanisme de détection d'erreur sur les liaisons de l'époque, peu fiables. Les $128$ codes de l'ASCII suffisaient à l'anglais, et le bit restant valait mieux comme sécurité de transmission. C'est ce huitième bit libéré qui accueillera plus tard les extensions nationales, dont Latin-1, avec les incompatibilités que l'on sait.

Avant 1985, chaque constructeur avait son propre format de flottants, avec des tailles, des arrondis et des comportements différents devant le zéro et l'infini. Un même programme scientifique donnait des résultats différents d'une machine à l'autre, et parfois faux. La norme est devenue indispensable dès que les programmes ont circulé et que les résultats de calcul ont dû être reproductibles.

Deux dates parce que ce sont deux choses différentes : Unicode définit le répertoire de caractères, UTF-8 définit une façon de le mettre en octets. UTF-8 s'est imposé pour deux raisons décisives : il est compatible avec ASCII, donc les milliards de fichiers et de protocoles existants sont restés valides sans modification, et il est économique, un texte occidental n'occupant guère plus de place qu'en ASCII, là où UTF-32 le quadruplerait.

Toutes quatre montrent qu'une norme, en informatique, ne sert pas à imposer la meilleure solution technique dans l'absolu, mais à permettre à des machines et à des programmes écrits par des gens différents d'échanger sans se tromper sur le sens des bits.

Partie entière : $1011_{2} = 8 + 2 + 1 = 11$. Partie fractionnaire : $0110$ donne $\frac{1}{4} + \frac{1}{8} = 0{,}375$. L'octet représente $11{,}375$. Autre lecture, très utile : l'octet vu comme un entier vaut $182$, et $\frac{182}{16} = 11{,}375$ ; un nombre en virgule fixe est un entier divisé par $2^{4} = 16$.

La plus grande valeur est $1111{,}1111$, soit $\frac{255}{16} = 15{,}9375$. Deux valeurs voisines diffèrent de $\frac{1}{16} = 0{,}0625$ : c'est la RÉSOLUTION, la même partout, contrairement aux flottants dont l'écart grandit avec la valeur.

$6{,}8 \times 16 = 108{,}8$. En tronquant, on garde 108, soit $0110{,}1100$, qui vaut $6{,}75$ : erreur $0{,}05$. En arrondissant, on garde 109, soit $0110{,}1101$, qui vaut $6{,}8125$ : erreur $0{,}0125$. Dans les deux cas $6{,}8$ n'est pas représentable exactement, pour la même raison que $0{,}1$ en flottant : son dénominateur n'est pas une puissance de 2.

Chaque nombre est un entier divisé par 16, donc $\frac{a}{16} + \frac{b}{16} = \frac{a + b}{16}$ : on additionne les entiers et la virgule reste au même endroit. $3{,}25$ correspond à 52 et $5{,}5$ à 88 ; $52 + 88 = 140$, soit $\frac{140}{16} = 8{,}75$, codé $1000{,}1100$. C'est tout l'intérêt de la virgule fixe : un processeur sans calcul flottant sait le faire.

$\frac{a}{16} \times \frac{b}{16} = \frac{a \times b}{256}$ : le produit des entiers est seize fois trop grand pour être relu en virgule fixe. $40 \times 24 = 960$, et $\frac{960}{16} = 60$, qui se relit $\frac{60}{16} = 3{,}75 = 2{,}5 \times 1{,}5$. Il faut donc diviser par 16, c'est-à-dire décaler de 4 bits vers la droite, après chaque multiplication.

$6 = 110_{2}$ et $0{,}25 = \frac{1}{4} = 0{,}01_{2}$, donc $6{,}25 = 110{,}01_{2}$.

On déplace la virgule de deux rangs vers la gauche : $110{,}01_{2} = 1{,}1001_{2} \times 2^{2}$. Donc $E = 2$, et la mantisse commence par $1001$ ; le 1 placé avant la virgule n'est PAS stocké, puisqu'il vaut toujours 1.

Exposant stocké : $2 + 127 = 129 = 128 + 1 = 10000001_{2}$. Le décalage évite de coder un signe pour l'exposant : les exposants négatifs correspondent aux valeurs stockées inférieures à 127.

Signe 1 pour un nombre négatif, exposant $10000001$, mantisse $1001$ suivie de 19 zéros. Les 32 bits s'écrivent $1\,10000001\,1001000\ldots0$, regroupés par quatre : $1100\ 0000\ 1100\ 1000\ 0000\ 0000\ 0000\ 0000$, soit $\mathrm{0xC0C80000}$. Le piège est d'oublier le bit de signe devant l'exposant, ce qui décale tous les regroupements.

$\mathrm{0x41200000}$ s'écrit $0100\ 0001\ 0010\ 0000\ \ldots$ Signe 0 : positif. Exposant $10000010_{2} = 130$, donc $E = 130 - 127 = 3$. Mantisse $01$ suivie de zéros : $1{,}01_{2} = 1{,}25$. Valeur : $1{,}25 \times 2^{3} = 10$. Le flottant vaut $10{,}0$.

ord('A') vaut 65 et chr(97) vaut 'a', comme en ASCII. ord('é') vaut 233, soit $\mathrm{U+00E9}$ : ord renvoie le point de code Unicode, pas un octet de l'encodage. chr(8364) vaut '€', de point de code $\mathrm{U+20AC}$.

Les minuscules sont 32 rangs après les majuscules : return chr(ord(c) - 32). On peut aussi écrire chr(ord(c) - ord('a') + ord('A')), qui ne demande de retenir aucun nombre.

ord('Z') vaut 90, donc chr(91) vaut '[' : après Z, la table ne recommence pas à A, elle continue avec des symboles. Un décalage doit donc ramener la position dans l'alphabet par un modulo 26 : chr((ord(c) - 65 + k) % 26 + 65).

Les caractères valent 3 + 2 + 1 = 6 octets. Sous Linux, trois fins de ligne d'un octet : 9 octets. Sous Windows, trois paires '\r\n' de deux octets : 12 octets. Le même texte n'a pas la même taille selon le système, sans qu'aucun caractère visible ne diffère.

len('abc\nde\nf\n') vaut 9 : '\n' est UN caractère, même s'il s'écrit avec deux symboles dans le code source. En cherchant '\n', le programme trouve bien trois lignes, mais la première lue vaut 'abc\r' : elle contient un retour chariot invisible, et la comparaison avec 'abc' échoue. D'où l'habitude de retirer les fins de ligne avec strip, ou d'ouvrir les fichiers en mode texte, qui convertit '\r\n' en '\n'.

Sur 1 octet, 7 bits libres : jusqu'à $2^{7} - 1 = 127 = \mathrm{0x7F}$. Sur 2 octets, $5 + 6 = 11$ bits : jusqu'à $2^{11} - 1 = 2\ 047 = \mathrm{0x7FF}$. Sur 3 octets, $4 + 6 + 6 = 16$ bits : jusqu'à $\mathrm{0xFFFF}$. Sur 4 octets, $3 + 6 + 6 + 6 = 21$ bits.

$\mathrm{0x20AC}$ dépasse $\mathrm{0x7FF}$ mais pas $\mathrm{0xFFFF}$ : il faut 3 octets. En binaire sur 16 bits : $0010\ 0000\ 1010\ 1100$. On répartit 4, 6 et 6 bits : $0010$, puis $000010$, puis $101100$. Les octets sont $1110\,0010$, $10\,000010$ et $10\,101100$, soit $\mathrm{E2\ 82\ AC}$.

$\mathrm{E4} = 1110\,0100$ annonce 3 octets et porte $0100$. $\mathrm{B8} = 10\,111000$ porte $111000$. $\mathrm{AD} = 10\,101101$ porte $101101$. En recollant : $0100\ 111000\ 101101 = 0100\ 1110\ 0010\ 1101_{2} = \mathrm{0x4E2D}$. C'est le point de code $\mathrm{U+4E2D}$, un idéogramme chinois qui signifie « milieu ».

La chaîne compte 11 caractères : P, r, i, x, espace, deux-points, espace, 2, 0, espace et €. Les dix premiers sont en ASCII, un octet chacun ; l'euro en prend trois. Total : $10 + 3 = 13$ octets.

Les 12 premiers octets contiennent les 10 caractères ASCII et les 2 premiers octets de l'euro : la séquence est incomplète, et l'affichage montre un symbole de remplacement ou déclenche une erreur de décodage. Pour reculer au début d'un caractère, il suffit de regarder les octets à partir de la coupure : tout octet de la forme $10xxxxxx$ est une continuation ; on recule tant qu'on en rencontre, puis on coupe avant l'octet de tête trouvé. Ici on coupe à 10 octets.

(1e16 + 1.0) - 1e16 vaut 0.0 : $10^{16} + 1$ n'est pas représentable, car l'écart entre flottants voisins y vaut 2, et il est arrondi à $10^{16}$ ; la soustraction donne 0. (1e16 - 1e16) + 1.0 vaut 1.0 : la soustraction est exacte et le 1 est ajouté à 0. Même opérations, ordre différent, résultats différents : l'addition flottante n'est pas associative.

Autour de $10^{16}$, au-delà de $2^{53}$, l'écart vaut 2. Autour de 1, il vaut $2^{-52} \approx 2{,}2 \times 10^{-16}$. L'écart est proportionnel à l'ordre de grandeur : c'est pour cela qu'on parle d'environ 16 chiffres significatifs, et non de 16 décimales.

Non : la boucle donne 0.9999999999999999, et le test d'égalité avec 1.0 est faux. Les dix petites erreurs d'arrondi se cumulent au lieu de se compenser.

Le résultat obtenu en commençant par les PETITS termes est le plus précis. En partant de 1, la somme atteint vite 10 puis 14, et chaque petit terme $\frac{1}{k}$ est ajouté à un grand nombre : il subit l'arrondi à l'échelle de ce grand nombre, et les erreurs s'accumulent sur un million d'additions. En partant des petits, ils s'additionnent d'abord entre eux, à leur propre échelle, et leur somme n'est absorbée qu'une fois devenue significative. On mesure un écart de l'ordre de $10^{-13}$ entre les deux ordres, l'ordre croissant des termes étant environ quinze fois plus proche de la valeur exacte.

math.fsum([0.1] * 10) == 1.0 vaut True : fsum garde la trace des erreurs d'arrondi et les réinjecte. On travaille plutôt en ENTIERS dès que le résultat doit être exact par nature, comme des montants d'argent comptés en centimes ou des durées comptées en millisecondes : un entier ne subit aucun arrondi, et l'égalité redevient un test fiable.