$course$/QCM de NSI/Première/Représentation des réels Représentation des nombres réels en machine, virgule fixe et
virgule flottante, norme IEEE 754, précision et erreurs
d'arrondi, conséquences pratiques sur les calculs.

]]> Représentation des réels — Q01 : Type des réels en Python Quel est le type Python utilisé pour représenter les
nombres à virgule ?

]]> Les nombres flottants sont approchés. Pour des calculs qui
doivent rester exacts, comme des montants en centimes, on préfère
travailler avec des entiers (int).

]]> 1.0 0.0 0 true true abc number

]]> Erreur : number n'est pas un type Python standard.

]]> float

]]> Bonne réponse : float (« nombre à virgule
flottante ») est le type Python pour les nombres
réels approchés. Par défaut, ils sont codés sur $64$
bits selon la norme IEEE $754$.

]]> int

]]> Erreur : int est le type des entiers en Python.

]]> real

]]> Erreur : real n'existe pas en Python (mais existe
dans certains autres langages comme Pascal).

]]> Représentation des réels — Q02 : Notation scientifique L'écriture scientifique d'un nombre réel sépare un
réel en :

]]> En base $2$ (binaire), la notation scientifique s'écrit
$m \times 2^e$, avec une mantisse $m$ entre $1$ et $2$
et un exposant $e$ entier. C'est exactement ce que fait
la norme IEEE $754$.

]]> 1.0 0.0 0 true true abc Une fraction irréductible

]]> Une fraction irréductible
(comme $\dfrac{3}{7}$) est
une autre façon d'écrire
un rationnel, mais ce n'est
pas la notation scientifique
en base deux utilisée par
les flottants.

]]> Une partie entière et une partie décimale

]]> Erreur : c'est plutôt l'écriture habituelle en base
$10$. La notation scientifique factorise en mantisse
et exposant.

]]> Un signe et une valeur absolue

]]> Erreur : c'est une décomposition différente, qui
n'est pas spécifiquement scientifique.

]]> Une mantisse et un exposant de $10$

]]> Bonne réponse : par exemple, $345{,}67 = 3{,}4567 \times 10^2$.
La mantisse est $3{,}4567$, l'exposant est $2$.
C'est l'idée de base de la représentation à virgule
flottante (en base $2$ pour les ordinateurs).

]]> Représentation des réels — Q03 : Norme IEEE 754 Que définit la norme IEEE $754$ ?

]]> Avant IEEE $754$, chaque constructeur avait son propre
format flottant, un même calcul pouvait donner des
résultats différents selon la machine. La norme a
uniformisé tout cela.

]]> 1.0 0.0 0 true true abc La représentation binaire des flottants

]]> Bonne réponse : la norme IEEE $754$ ($1985$, révisée
en $2008$ et $2019$) standardise les formats de
flottants : simple précision (float, $32$ bits),
double précision (double, $64$ bits) et plus.
Pratiquement tous les processeurs respectent cette
norme.

]]> La connectique des câbles réseau

]]> Erreur : aucun rapport. La connectique des câbles réseau relève
d'autres normes, sans lien avec la représentation des nombres.

]]> Le format des adresses IP

]]> Erreur : le format des adresses IP est fixé par les protocoles
d'internet. IEEE $754$ concerne les réels.

]]> Le format standard des fichiers PDF

]]> Erreur : le format PDF est défini par sa propre spécification. Il
n'a aucun lien avec la norme IEEE $754$, qui concerne uniquement
les nombres flottants.

]]> Représentation des réels — Q04 : Approximation des réels Pourquoi les réels stockés en machine sont-ils en général
des approximations plutôt que des valeurs exactes ?

]]> C'est une limite fondamentale : aucun ordinateur,
quelle que soit sa puissance, ne peut représenter
exactement tous les réels. Il faut donc choisir un
compromis sur la précision et l'étendue.

]]> 1.0 0.0 0 true true abc Parce qu'il y a une infinité de nombres réels mais une mémoire finie

]]> Bonne réponse : on ne peut représenter qu'un nombre
fini de valeurs en mémoire finie. La plupart des
réels (par exemple $\pi$, $\sqrt{2}$) doivent être
approchés. Même certains nombres « simples » comme
$0{,}1$ n'ont pas de représentation binaire finie.

]]> Parce que les ordinateurs sont mal conçus

]]> Erreur : ce n'est pas un défaut de conception, c'est
une nécessité mathématique.

]]> Parce qu'il faut moins de mémoire

]]> Erreur : c'est pour des raisons mathématiques
fondamentales, pas seulement d'optimisation.

]]> Parce que les flottants sont plus rapides que les entiers

]]> Erreur : les flottants sont en réalité plus lents
que les entiers sur la plupart des processeurs.

]]> Représentation des réels — Q05 : Calcul flottant en Python Que renvoie l'expression Python 0.1 + 0.2 ?

]]> $0{,}1$ en binaire vaut
$0{,}0001100110011\ldots$ (motif périodique infini).
L'arrondi à un nombre fini de bits crée une petite
erreur, qui se propage dans les calculs.

]]> 1.0 0.0 0 true true abc Une erreur Python

]]> Erreur : aucune erreur, le calcul est valide. Mais
son résultat n'est pas exactement $0{,}3$.

]]> Exactement $0{,}3$

]]> Erreur : $0{,}1$ et $0{,}2$ n'ont pas de
représentation binaire finie (comme $1/3$ en
base $10$). Leur somme contient donc une erreur
d'arrondi.

]]> $0{,}29999\ldots$ (donc sans la moindre erreur)

]]> Erreur : la valeur exacte stockée est légèrement
supérieure à $0{,}3$, pas inférieure.

]]> Proche de $0{,}3$, avec une erreur d'arrondi

]]> Bonne réponse : c'est l'exemple emblématique des
pièges du calcul flottant. Pour comparer des
flottants, on utilise typiquement
abs(a - b) < epsilon.

]]> Représentation des réels — Q06 : Comparer deux flottants Pour tester si deux flottants a et b sont « égaux »
en Python, la bonne pratique est :

]]> Cette précaution est essentielle dans tous les calculs
scientifiques. Les comparaisons strictes de flottants
sont une source classique de bugs subtils.

]]> 1.0 0.0 0 true true abc a == b

]]> Erreur : à cause des erreurs d'arrondi, deux
flottants qui devraient être égaux peuvent
légèrement différer. == est trop strict.

]]> round(a, 2) == round(b, 2)

]]> Erreur : un arrondi ne joue pas le rôle d'une
tolérance. Deux flottants très proches mais situés de
part et d'autre d'une frontière d'arrondi (comme
$1{,}004\,999$ et $1{,}005\,001$) sont déclarés
différents, alors que deux valeurs qui s'écartent de
presque un centième sont déclarées égales.

]]> abs(a - b) < epsilon

]]> Bonne réponse : on compare l'écart à une tolérance
epsilon choisie petite (par exemple $10^{-9}$), au
lieu d'exiger une égalité exacte. Le choix
d'epsilon dépend du contexte.

]]> int(a) == int(b)

]]> Erreur : int supprime la partie décimale, ce qui ne mesure pas
l'écart : int(2.1) == int(2.9) vaut True alors que les deux
flottants diffèrent de $0{,}8$.

]]> Représentation des réels — Q07 : Virgule fixe Quelle est la différence entre une représentation à
virgule fixe et une représentation à virgule flottante ?

]]> Cas typique de virgule fixe : la finance, où on
manipule des montants à deux décimales, et on veut
éviter les erreurs d'arrondi sur l'argent. On stocke
alors les montants en centimes (entiers).

]]> 1.0 0.0 0 true true abc Fixe = décimales constantes, flottante = précision relative

]]> Bonne réponse : avec virgule fixe, par exemple
deux décimales, on peut représenter $0{,}01$ à
$9999{,}99$. Avec virgule flottante, l'exposant
permet d'aller de très petit ($10^{-300}$) à très
grand ($10^{300}$), au prix d'une précision relative.

]]> La virgule fixe n'existe que sur les vieux ordinateurs

]]> Erreur : la virgule fixe est encore utilisée
aujourd'hui (par exemple en finance pour des
montants en centimes).

]]> Aucune différence en pratique

]]> Erreur : les différences sont importantes,
notamment pour des applications spécifiques.

]]> La virgule fixe est plus précise pour les très grands nombres

]]> Erreur : c'est plutôt la virgule flottante qui gère
mieux les très grands ou très petits nombres
(grâce à l'exposant variable).

]]> Représentation des réels — Q08 : Taille d'un float Python En Python, sur combien de bits est stocké un float ?

]]> Avec $64$ bits, on ne peut coder qu'un nombre fini de valeurs : la
plupart des réels, comme $0{,}1$, ne sont donc stockés que de façon
approchée.

]]> 1.0 0.0 0 true true abc $128$ bits

]]> Erreur : la quadruple précision ($128$ bits) existe
mais n'est pas le standard de Python.

]]> $64$ bits

]]> Bonne réponse : Python utilise par défaut la double
précision IEEE $754$, soit $64$ bits ($1$ pour le
signe, $11$ pour l'exposant, $52$ pour la mantisse).
Cela donne environ $15$ à $17$ chiffres décimaux
significatifs.

]]> $8$ bits

]]> Erreur : trop peu pour représenter une plage utile
de réels.

]]> $32$ bits

]]> Erreur : c'est la simple précision (le type
float du langage C). Python utilise par défaut la
double précision.

]]> Représentation des réels — Q09 : Écrire un quart en base deux Quelle est l'écriture en base $2$ du nombre décimal $0{,}25$ ?

]]> Après la virgule, les rangs en base $2$ valent $\frac{1}{2}$,
$\frac{1}{4}$, $\frac{1}{8}$, etc. Comme $0{,}25 = \frac{1}{4} = 2^{-2}$,
son écriture binaire est finie et courte : $0{,}01_2$. Ce nombre
est donc stocké exactement dans un flottant, contrairement à
$0{,}1$.

]]> 1.0 0.0 0 true true abc $0{,}1_2$

]]> Erreur : $0{,}1_2$ vaut $2^{-1} = 0{,}5$. Le premier chiffre
après la virgule compte les demis, or $0{,}25$ est plus petit
qu'un demi.

]]> $0{,}01_2$

]]> Bonne réponse : $0{,}25 = \frac{1}{4} = 2^{-2}$. On a
$0{,}25 \times 2 = 0{,}5$ (chiffre $0$), puis $0{,}5 \times 2 = 1$ (chiffre $1$) : l'écriture s'arrête là.

]]> $0{,}11_2$

]]> Erreur : $0{,}11_2$ vaut $0{,}5 + 0{,}25 = 0{,}75$. Le rang des
demis doit rester à $0$, puisque $0{,}25$ est plus petit qu'un demi.

]]> $0{,}25_2$

]]> Erreur : en base $2$, seuls les chiffres $0$ et $1$ existent. On
ne recopie pas l'écriture décimale après la virgule.

]]> Représentation des réels — Q10 : Deux assertions sur des moyennes Pour tester une fonction moyenne, on exécute le
programme suivant :

def moyenne(a, b):
    return (a + b) / 2

assert moyenne(0.25, 0.75) == 0.5
assert moyenne(0.1, 0.2) == 0.15

Que se passe-t-il ?

]]> Un nombre a une écriture binaire finie seulement
s'il est une somme d'un nombre fini de puissances
de $2$, comme $0{,}75 = 2^{-1} + 2^{-2}$. Ce n'est
pas le cas de $0{,}1 = 0{,}0001100110011\ldots_2$,
qui est arrondi. Pour tester un résultat flottant,
on compare l'écart à une tolérance :
assert abs(moyenne(0.1, 0.2) - 0.15) < 1e-9.

]]> 1.0 0.0 0 true true abc Les deux assertions sont vérifiées, le programme se termine sans erreur

]]> Erreur : $0{,}1$ et $0{,}2$ n'ont pas d'écriture
binaire finie, ils sont stockés arrondis. Leur
moyenne vaut 0.15000000000000002, et l'égalité
avec 0.15 est fausse.

]]> La première assertion est vérifiée, la seconde lève AssertionError

]]> Bonne réponse : $0{,}25 = 0{,}01_2$ et
$0{,}75 = 0{,}11_2$ s'écrivent exactement en
binaire, donc la première moyenne vaut
exactement $0{,}5$. En revanche, $0{,}1$ et $0{,}2$
sont arrondis : leur moyenne vaut
0.15000000000000002, et la seconde égalité est
fausse.

]]> La première assertion lève AssertionError et arrête le programme

]]> Erreur : $0{,}25$, $0{,}75$ et $0{,}5$ sont des sommes
de puissances de $2$ ($0{,}01_2$, $0{,}11_2$ et
$0{,}1_2$) : ils sont représentés exactement, et
la première égalité est vraie.

]]> Python refuse d'évaluer == entre deux flottants et lève une erreur

]]> Erreur : == s'applique aux flottants comme aux
entiers. Il est seulement déconseillé, car deux
calculs censés donner la même valeur peuvent
différer à cause des arrondis.

]]> Représentation des réels — Q11 : Erreur d'arrondi cumulative Que peut-il se passer si on additionne plusieurs millions
de petits flottants entre eux ?

]]> Un exemple frappant : additionner dix fois 0.1 dans une boucle
for donne 0.9999999999999999, pas $1{,}0$, à cause des erreurs
cumulées. Pour des montants, on compte en centimes avec des
entiers.

]]> 1.0 0.0 0 true true abc Le résultat est exact, comme une somme d'entiers

]]> Erreur : chaque addition introduit une petite erreur
d'arrondi. Sur des millions d'opérations, ces
erreurs s'accumulent.

]]> Le calcul devient infiniment lent

]]> Erreur : la vitesse n'est pas l'enjeu. C'est la
précision qui se dégrade.

]]> Python lève une erreur de précision

]]> Erreur : aucune erreur n'est levée. Les calculs
flottants sont silencieusement approximatifs.

]]> Les erreurs d'arrondi s'accumulent et faussent le résultat

]]> Bonne réponse : c'est un piège classique en calcul scientifique.
Chaque addition arrondit un peu, et sur des millions d'opérations
ces écarts s'additionnent. Quand c'est possible, on travaille avec
des entiers, qui restent exacts.

]]> Représentation des réels — Q12 : Un prix calculé qui échappe au test Un programme compte les articles vendus $0{,}30$ euro :

prix = [0.1 + 0.2, 0.5, 0.3]
compte = 0
for p in prix:
    if p == 0.3:
        compte = compte + 1
print(compte)

Qu'affiche ce programme ?

]]> Le programme illustre la règle : il faut éviter de tester l'égalité
de deux flottants. Avec la condition abs(p - 0.3) < 1e-9, les
deux prix de $0{,}30$ euro seraient comptés.

]]> 1.0 0.0 0 true true abc 2

]]> Erreur : 0.1 + 0.2 ne vaut pas 0.3 en Python mais
0.30000000000000004. Le test p == 0.3 est donc faux pour le
premier prix, et seul le dernier est compté.

]]> 1

]]> Bonne réponse : seul le dernier prix, écrit directement 0.3,
passe le test. Le premier, calculé, vaut 0.30000000000000004 et
échoue à l'égalité stricte.

]]> 0

]]> Erreur : l'égalité entre flottants n'est pas toujours fausse. Le
dernier élément de la liste et le littéral 0.3 du test sont
exactement le même flottant, le test réussit pour ce prix.

]]> Une erreur, car == ne compare pas des flottants

]]> Erreur : == s'applique aux flottants et renvoie un booléen. Le
programme s'exécute sans erreur ; c'est le résultat du test qui
surprend.

]]> Représentation des réels — Q13 : Valeur décimale d'une écriture binaire à virgule Quelle est la valeur décimale du nombre écrit en base $2$ :
$110{,}01_2$ ?

]]> Chaque rang a un poids : des puissances de $2$ avant la virgule, puis
$\frac{1}{2}$, $\frac{1}{4}$, $\frac{1}{8}$ après. On additionne
les poids des chiffres $1$ : $4 + 2 + \frac{1}{4} = 6{,}25$.

]]> 1.0 0.0 0 true true abc $6{,}01$

]]> Erreur : la partie entière $110_2 = 6$ est juste, mais les
chiffres après la virgule ne se recopient pas : $0{,}01_2$ vaut
$0{,}25$.

]]> $6{,}5$

]]> Erreur : $0{,}01_2$ n'est pas un demi. Chaque rang après la
virgule a son poids, $\frac{1}{2}$, $\frac{1}{4}$, $\frac{1}{8}$,
d'où $0{,}25$.

]]> $6{,}25$

]]> Bonne réponse : $110_2 = 4 + 2 = 6$ et
$0{,}01_2 = 0 \times \frac{1}{2} + 1 \times \frac{1}{4} = 0{,}25$,
soit $6{,}25$.

]]> $3{,}25$

]]> Erreur : on a lu la partie entière à l'envers, comme
$011_2 = 3$. Le chiffre de gauche a le poids le plus fort :
$110_2 = 4 + 2 = 6$.

]]> Représentation des réels — Q15 : Calcul financier Pour un calcul financier (additionner des centimes),
quel choix est le plus prudent en Python ?

]]> Les erreurs d'arrondi des float sont inacceptables pour des
montants : la précision doit être garantie au centime. Compter en
centimes avec des entiers supprime le problème.

]]> 1.0 0.0 0 true true abc Utiliser des float

]]> Erreur : les flottants accumulent des erreurs
d'arrondi qui peuvent fausser des montants en
centimes. Mauvaise pratique financière.

]]> Utiliser des nombres complexes en Python

]]> Erreur : aucun rapport avec les nombres complexes.

]]> Stocker les montants en centimes entiers

]]> Bonne réponse : les entiers sont exacts en Python. On compte en
centimes et on ne convertit en euros qu'au moment de l'affichage.

]]> Utiliser des chaînes de caractères

]]> Erreur : on ne peut pas faire d'arithmétique
directement sur des chaînes en Python.

]]> Représentation des réels — Q16 : Conversion entier vers flottant En Python, l'instruction float(7) renvoie :

]]> Inversement, int(7.9) renvoie $7$ (troncature, pas
arrondi). Pour arrondir, on utilise round(7.9) qui
renvoie $8$.

]]> 1.0 0.0 0 true true abc 7 (entier inchangé)

]]> Erreur : la fonction float change le type. Le
résultat est 7.0, qui est un flottant.

]]> 7.0 (flottant)

]]> Bonne réponse : la conversion d'un entier en
flottant ajoute « .0 ». Le type passe de int à
float.

]]> Une erreur

]]> Erreur : aucune erreur, c'est une conversion
standard.

]]> '7' (chaîne de caractères)

]]> Erreur : float() convertit en flottant, pas en
chaîne. Pour une chaîne, on utiliserait str(7).

]]> Représentation des réels — Q17 : Perte de signification Pourquoi (1e16 + 1) - 1e16 donne-t-il $0$ en Python
au lieu de $1$ ?

]]> Pour éviter ce piège : reformuler les calculs pour
éviter de soustraire des nombres très proches, ou
passer en précision étendue. C'est un problème
classique du calcul numérique scientifique.

]]> 1.0 0.0 0 true true abc $1$ est négligeable face à $10^{16}$ pour la mantisse

]]> Bonne réponse : la double précision a environ $16$
chiffres significatifs. Quand on ajoute $1$ à
$10^{16}$, le $1$ est « écrasé » par les erreurs
d'arrondi. C'est la perte de signification
(loss of significance).

]]> Parce que Python ne sait pas additionner

]]> Erreur : Python sait additionner. La limitation
vient du format de représentation des flottants.

]]> Parce que les nombres trop grands sont arrondis à zéro

]]> Erreur : ce n'est pas l'arrondi à zéro, c'est plus
subtil : c'est la précision relative limitée.

]]> C'est un bug de Python

]]> Erreur : ce n'est pas un bug, c'est un comportement
attendu et défini par IEEE $754$.

]]> Représentation des réels — Q18 : Forme normalisée En base $2$, la notation scientifique normalisée d'un réel non
nul a la forme :

]]> C'est l'analogue de la notation scientifique décimale, où l'on écrit
$350 = 3{,}5 \times 10^{2}$ avec un seul chiffre non nul avant la
virgule. En base $2$, ce chiffre ne peut être que $1$.

]]> 1.0 0.0 0 true true abc $0{,}m \times 2^e$ avec $m$ quelconque

]]> Erreur : la forme normalisée place un seul chiffre, qui vaut $1$,
avant la virgule : sa mantisse est comprise entre $1$ et $2$, pas
entre $0$ et $1$.

]]> $1{,}m \times 2^e$

]]> Bonne réponse : en binaire, le premier chiffre non nul d'un nombre
est toujours $1$. On place la virgule juste après ce $1$ et on
compense par la puissance de $2$ : par exemple
$6 = 110_2 = 1{,}1_2 \times 2^{2}$.

]]> $m \times 10^e$ avec $m$ et $e$ entiers

]]> Erreur : la base est $2$, pas $10$. Et la mantisse
n'est pas toujours entière.

]]> $m + e$ (somme)

]]> Erreur : la mantisse et l'exposant ne s'additionnent
pas, ils se combinent par produit ($m \times 2^e$).

]]> Représentation des réels — Q19 : Non-associativité de l'addition flottante En arithmétique flottante, l'addition est-elle toujours
associative (c'est-à-dire $(a + b) + c = a + (b + c)$) ?

]]> Cette non-associativité a des implications concrètes :
en parallélisme, des sommes massives peuvent donner
des résultats légèrement différents selon l'ordre de
réduction. En science du calcul, on cherche des
algorithmes qui minimisent cette dépendance.

]]> 1.0 0.0 0 true true abc Cela dépend du système d'exploitation

]]> Erreur : pas de lien avec le système.

]]> Cela dépend du langage de programmation

]]> Erreur : c'est une propriété de la norme IEEE $754$,
indépendante du langage.

]]> Non, l'ordre des additions change le résultat

]]> Bonne réponse : par exemple,
(1e16 + 1) - 1e16 = 0 mais (1e16 - 1e16) + 1 = 1.
Ce détail est crucial en programmation parallèle :
additionner dans un ordre différent peut donner un
résultat différent.

]]> Oui, exactement comme pour les entiers

]]> Erreur : c'est une croyance répandue mais fausse !
À cause des arrondis, l'ordre des additions peut
changer le résultat.

]]> Représentation des réels — Q20 : Décimal vs binaire Pourquoi $0{,}5$ a une représentation binaire exacte,
mais pas $0{,}1$ ?

]]> C'est l'analogue de $1/3 = 0{,}333\ldots$ en base $10$. Toute base
privilégie certaines fractions et en désavantage d'autres. Pour des
montants, compter en centimes avec des entiers évite ce problème.

]]> 1.0 0.0 0 true true abc Parce que $0{,}5$ est plus grand que $0{,}1$

]]> Erreur : aucune raison liée à la taille relative.

]]> Parce que $0{,}5$ est utilisé plus souvent

]]> Erreur : la fréquence d'usage n'a rien à voir avec
la représentabilité.

]]> Parce que $0{,}5$ a un seul chiffre, $0{,}1$ aussi

]]> Erreur : c'est en base $10$. En binaire, la
longueur des deux écritures est très différente.

]]> $0{,}5 = 2^{-1}$ est une puissance de $2$, pas $0{,}1$

]]> Bonne réponse : en base $2$, seules les fractions
dont le dénominateur est une puissance de $2$
(ou des sommes de telles fractions) ont une
représentation finie. Pour $1/10$, on obtient
$0{,}0001100110011\ldots_2$, périodique infini.

]]> Représentation des réels — Q23 : Propagation des erreurs Avec des flottants, quel calcul fait perdre le plus de chiffres
significatifs exacts parmi les suivants ?

]]> Exemple : en Python, 1.0000001 - 1.0 affiche
1.0000000005838672e-07 au lieu de 1e-07. Les chiffres de tête
communs s'annulent, et il ne reste que des chiffres dont une partie
provient des erreurs d'arrondi.

]]> 1.0 0.0 0 true true abc $a - b$ avec $a$ et $b$ très proches

]]> Bonne réponse : si $a$ et $b$ sont très proches,
leur différence a beaucoup moins de chiffres
significatifs que $a$ ou $b$. Les erreurs d'arrondi
deviennent dominantes par rapport au résultat.

]]> $a + b$ pour $a$ et $b$ de même signe

]]> Erreur : ajouter deux nombres de même signe conserve les premiers
chiffres du résultat ; les erreurs d'arrondi restent petites
devant lui.

]]> $a \times b$ pour $a$ et $b$ proches de $1$

]]> Erreur : multiplier deux nombres proches de $1$ donne un résultat
proche de $1$, dont les erreurs d'arrondi restent du même ordre que
celles des facteurs.

]]> $a / b$ quand $b$ est grand

]]> Erreur : diviser par un grand nombre donne un petit résultat, mais
ses chiffres significatifs restent aussi exacts que ceux de $a$ et
$b$.

]]> Représentation des réels — Q24 : Une tolérance mal dimensionnée Sarah compare deux flottants avec une tolérance fixe :

def proches(a, b):
    return abs(a - b) < 1e-9

print(proches(1e-12, 2e-12))

Le programme affiche True, alors que 2e-12 est le
double de 1e-12. Comment expliquer ce résultat ?

]]> Une tolérance absolue ne vaut que pour un ordre de grandeur
donné : $10^{-9}$ convient pour des valeurs proches de $1$,
mais tout écart entre des valeurs de l'ordre de $10^{-12}$
lui est inférieur. Quand l'ordre de grandeur n'est pas connu
d'avance, on compare l'écart à une fraction des valeurs
elles-mêmes (tolérance relative).

]]> 1.0 0.0 0 true true abc La tolérance $10^{-9}$ est énorme devant les valeurs comparées, il faut l'adapter à leur ordre de grandeur

]]> Bonne réponse : l'écart réel vaut $10^{-12}$, mille fois
plus petit que la tolérance, donc le test réussit quelle
que soit la différence entre a et b. Une tolérance
fixe n'a de sens que pour des valeurs d'ordre de grandeur
connu ; sinon, on la rend relative, par exemple
abs(a - b) < 1e-9 * abs(b), qui renvoie ici False.

]]> Les deux valeurs sont plus petites que le plus petit flottant représentable et valent donc toutes deux 0.0 en machine

]]> Erreur : un flottant $64$ bits descend jusqu'à environ
$10^{-308}$, bien en dessous de $10^{-12}$. Les deux
valeurs sont représentées et distinctes : 1e-12 == 2e-12
renvoie False.

]]> La soustraction de deux flottants aussi proches subit une annulation et renvoie exactement 0.0, d'où un écart nul

]]> Erreur : 1e-12 - 2e-12 renvoie -1e-12, un écart non
nul. L'annulation qui menace une soustraction concerne
des valeurs presque égales, pas des valeurs du simple au
double.

]]> Le test est correct, car deux flottants qui diffèrent de moins de $10^{-9}$ sont indiscernables pour la machine

]]> Erreur : la machine distingue parfaitement 1e-12 et
2e-12 ; l'indiscernabilité ne concerne que des écarts
relatifs de l'ordre de $10^{-16}$. C'est le seuil choisi
par Sarah qui est inadapté, pas la représentation.

]]> Représentation des réels — Q25 : Synthèse sur les flottants Parmi les énoncés suivants, lequel est vrai sur les
nombres flottants en machine ?

]]> Connaître les flottants permet d'éviter des bugs
subtils mais critiques dans les calculs scientifiques,
financiers, et même dans des programmes ordinaires
qui manipulent des nombres réels.

]]> 1.0 0.0 0 true true abc La précision des flottants augmente avec la taille du nombre

]]> Erreur : la précision relative est constante,
mais l'erreur absolue augmente avec la taille
du nombre. Plus un nombre est grand, plus l'écart
entre deux flottants consécutifs est grand.

]]> Les calculs flottants sont aussi précis que les calculs sur papier

]]> Erreur : on a vu de nombreux contre-exemples
(associativité, perte de signification, etc.). Les
calculs flottants sont approchés.

]]> Le test == entre flottants est piégeux, préférer une tolérance

]]> Bonne réponse : c'est l'enseignement le plus
pratique de tout ce chapitre. À cause des erreurs
d'arrondi, deux flottants qui devraient être égaux
peuvent légèrement différer. Toujours préférer une
comparaison à une tolérance, du type
abs(a - b) < epsilon.

]]> Les flottants peuvent représenter exactement tous les nombres rationnels

]]> Erreur : la plupart des rationnels (par exemple
$1/3$, $1/10$) n'ont pas de représentation finie
en binaire. Seul un sous-ensemble fini est
exactement représenté.

]]> Représentation des réels — Q26 : Conversion décimal vers binaire avec virgule Quelle est l'écriture binaire de $6{,}625$ ?

]]> Méthode pour la partie fractionnaire : on multiplie par $2$
et on note la partie entière du résultat (bit $0$ ou $1$),
puis on continue avec la partie fractionnaire restante,
jusqu'à obtenir $0$ ou repérer un cycle. Pour $0{,}625$, on
obtient $0{,}101_2$ exactement, car $0{,}625 = 0{,}5 + 0{,}125 = 2^{-1} + 2^{-3}$.

]]> 1.0 0.0 0 true true abc $1010{,}101$

]]> Erreur : $1010_2 = 10$, pas $6$. Confusion sur la partie
entière : $6 = 4 + 2 = 110_2$.

]]> $110{,}625$

]]> Erreur : on a juxtaposé l'écriture décimale de la partie
fractionnaire à la partie entière en binaire. La partie
décimale doit elle aussi être convertie en base $2$.

]]> $110{,}100$

]]> Erreur : $0{,}100_2$ vaut $0{,}5$, ce qui ne correspond pas
à $0{,}625$. Il faut poursuivre les multiplications par $2$
jusqu'à épuiser la partie fractionnaire.

]]> $110{,}101$

]]> Bonne réponse : la partie entière donne $6 = 110_2$. La
partie fractionnaire se calcule par multiplications
successives par $2$ : $0{,}625 \times 2 = 1{,}25$ (bit $1$), puis $0{,}25 \times 2 = 0{,}5$ (bit $0$), puis $0{,}5 \times 2 = 1{,}0$ (bit $1$). On obtient
$0{,}101_2$, d'où $110{,}101_2$.

]]> Représentation des réels — Q27 : Décimal sans écriture binaire finie Parmi les réels suivants (écrits en base $10$), lequel n'a
pas une écriture finie en base $2$ ?

]]> Un nombre décimal $\dfrac{p}{q}$ irréductible a une
écriture binaire finie si et seulement si $q$ est une
puissance de $2$. Pour $0{,}1 = \dfrac{1}{10}$,
$q = 10 = 2 \times 5$ contient un facteur $5$, ce qui
provoque le caractère infini en base $2$. Cette
observation explique pourquoi tant de calculs simples en
apparence ($0{,}1 + 0{,}2$) deviennent imprécis sur
machine.

]]> 1.0 0.0 0 true true abc $0{,}1$

]]> Bonne réponse : $0{,}1$ ne s'exprime pas comme une somme
finie de puissances négatives de $2$. Son écriture
binaire est périodique :
$0{,}0001100110011\ldots_2$. C'est précisément la cause
de l'écart entre 0.1 + 0.2 et 0.3 en flottant.

]]> $0{,}75$

]]> Erreur : $0{,}75 = 0{,}5 + 0{,}25 = 2^{-1} + 2^{-2}$,
donc son écriture binaire est $0{,}11_2$, finie sur
deux bits.

]]> $0{,}25$

]]> Erreur : $0{,}25 = 2^{-2}$, donc son écriture binaire est
$0{,}01_2$, finie sur deux bits.

]]> $0{,}5$

]]> Erreur : $0{,}5 = 2^{-1}$, donc son écriture binaire est
$0{,}1_2$, finie sur un seul bit fractionnaire.

]]> Représentation des réels — Q28 : Exposant biaisé en simple précision Le réel $5{,}5$ s'écrit en notation scientifique binaire
$5{,}5 = 1{,}011_2 \times 2^{2}$. Dans le format simple précision,
l'exposant n'est pas stocké tel quel : on lui ajoute $127$ avant de
l'écrire sur huit bits. Quelle suite de huit bits est stockée dans
ce champ ?

]]> Ajouter $127$ permet de ranger aussi les exposants négatifs dans un
champ de huit bits sans signe : un exposant réel $-1$ est stocké
$126$. Pour relire l'exposant, on retire $127$ à la valeur stockée.

]]> 1.0 0.0 0 true true abc $00000010_2$

]]> Erreur : $00000010_2 = 2$ est l'exposant réel, écrit sans lui
ajouter $127$ comme le demande le format.

]]> $01111101_2$

]]> Erreur : $01111101_2 = 125$ ; on a soustrait $127$ au lieu de
l'ajouter ($2 - 127 = -125$, puis on a oublié le signe). Le champ
contient $2 + 127 = 129$.

]]> $10000010_2$

]]> Erreur : $10000010_2 = 130$, soit $2 + 128$. Le décalage du format
vaut $127$ et non $128$ : le champ contient $129$.

]]> $10000001_2$

]]> Bonne réponse : l'exposant stocké est $2 + 127 = 129 = 128 + 1$, ce
qui s'écrit $10000001_2$ sur huit bits.

]]> Représentation des réels — Q29 : Décoder un flottant simple précision Un flottant est codé sur $32$ bits en simple précision :

0 | 10000001 | 01000000000000000000000

Le premier bit est le signe ; les $8$ bits suivants contiennent
l'exposant augmenté de $127$ ; les $23$ derniers contiennent les
chiffres après la virgule de la mantisse $1{,}\ldots_2$, dont le
$1$ de tête n'est pas stocké. Quelle est la valeur décimale
représentée ?

]]> Décodage en trois étapes : lire le bit de signe ; lire l'exposant
stocké $E$ et calculer $e = E - 127$ ; rétablir le $1$ devant les
chiffres de la mantisse, puis calculer
$(-1)^s \times 1{,}M_2 \times 2^e$. Ici :
$(-1)^0 \times 1{,}25 \times 2^{2} = 5$.

]]> 1.0 0.0 0 true true abc $1$

]]> Erreur : on a oublié de rétablir le $1$ non stocké devant la
virgule. La mantisse vaut $1{,}01_2 = 1{,}25$ et non
$0{,}01_2 = 0{,}25$ : la valeur est $1{,}25 \times 2^{2} = 5$, pas
$0{,}25 \times 2^{2} = 1$.

]]> $5$

]]> Bonne réponse : signe 0 (positif), exposant
$10000001_2 = 129$, donc $e = 129 - 127 = 2$. Mantisse
$1{,}01_2 = 1{,}25$. Valeur : $1{,}25 \times 2^{2} = 5$.

]]> $10$

]]> Erreur : $10 = 1{,}25 \times 2^{3}$, l'exposant réel a été surestimé
d'une unité. L'exposant stocké vaut $129$, donc $e = 2$ et le
facteur est $2^{2} = 4$, pas $2^{3} = 8$.

]]> $-5$

]]> Erreur : le bit de signe vaut $0$ (positif). Le résultat
est $+5$, pas $-5$.

]]> Représentation des réels — Q30 : Répartition des bits d'un flottant double précision Un float de Python suit le format double précision de la norme
IEEE $754$, sur $64$ bits. Comment ces bits se répartissent-ils ?

]]> Simple précision : $1$, $8$ et $23$ bits sur $32$. Double précision :
$1$, $11$ et $52$ bits sur $64$. Python utilise la seconde pour tous
ses float.

]]> 1.0 0.0 0 true true abc $1$ bit de signe, $11$ bits d'exposant, $52$ bits de mantisse

]]> Bonne réponse : $1 + 11 + 52 = 64$. Les $52$ bits de mantisse,
complétés par le $1$ implicite de tête, donnent environ seize
chiffres décimaux significatifs.

]]> $1$ bit de signe, $8$ bits d'exposant, $23$ bits de mantisse

]]> Erreur : ces trois champs totalisent $32$ bits. C'est la
répartition de la simple précision, pas celle du float de
Python.

]]> $32$ bits pour la partie entière, $32$ bits pour la partie décimale

]]> Erreur : ce découpage décrit une virgule fixe. Un flottant
sépare signe, exposant et mantisse, ce qui permet à la virgule
de se déplacer selon la grandeur du nombre.

]]> $1$ bit de signe, $31$ bits d'exposant, $32$ bits de mantisse

]]> Erreur : la somme fait bien $64$, mais l'exposant n'occupe que
$11$ bits. La majeure partie du mot, $52$ bits, est réservée à
la mantisse, qui fixe la précision.

]]> Représentation des réels — Q31 : Exposant biaisé en double précision En double précision (norme IEEE $754$ sur $64$ bits), l'exposant
est stocké sur $11$ bits, augmenté du biais $1023$. Quel champ
d'exposant représente le réel $2^{5}$, c'est-à-dire
$1{,}0_2 \times 2^{5}$ ?

]]> Le biais dépend de la taille du champ d'exposant : $127$ pour
$8$ bits, $1023$ pour $11$ bits. Dans les deux cas, la valeur
stockée est l'exposant réel augmenté du biais.

]]> 1.0 0.0 0 true true abc $10000000100_2$

]]> Bonne réponse : on stocke $5 + 1023 = 1028$, soit
$10000000100_2$ sur onze bits.

]]> $00000000101_2$

]]> Erreur : l'exposant n'est pas stocké tel quel. Le biais permet
de représenter aussi les exposants négatifs sans bit de signe
supplémentaire : il faut stocker $5 + 1023 = 1028$.

]]> $01111111010_2$

]]> Erreur : le biais s'ajoute à l'exposant, il ne s'en retranche
pas. La valeur $1023 - 5 = 1018$ représenterait
$2^{-5}$.

]]> $00010000100_2$

]]> Erreur : $127$ est le biais de la simple précision, dont
l'exposant tient sur $8$ bits. En double précision, le biais
vaut $1023$ et $127 + 5 = 132$ n'a pas de sens.

]]> Représentation des réels — Q32 : Écart entre deux flottants consécutifs En simple précision, la mantisse compte $23$ chiffres binaires
après la virgule. Tous les flottants compris entre $2^{3}$ et
$2^{4}$ partagent l'exposant $3$. Quel est l'écart entre deux
flottants consécutifs de cet intervalle ?

]]> La précision d'un flottant est relative : l'écart entre deux
valeurs consécutives vaut $2^{-23}$ fois la puissance de deux de
l'intervalle. Près de $1$, les flottants sont espacés d'environ
$10^{-7}$ ; près de $10^{6}$, d'environ $0{,}06$.

]]> 1.0 0.0 0 true true abc $2^{-20}$

]]> Bonne réponse : dans cet intervalle, la valeur s'écrit
$1{,}m_2 \times 2^{3}$ et le dernier chiffre de la mantisse
pèse $2^{-23}$. Deux flottants consécutifs diffèrent donc de
$2^{-23} \times 2^{3} = 2^{-20}$.

]]> $2^{-21}$

]]> Erreur : le $1$ implicite de tête se trouve avant la virgule,
il n'ajoute pas un vingt-quatrième chiffre après elle. Le
dernier chiffre pèse $2^{-23}$, d'où un écart de $2^{-20}$.

]]> $2^{-26}$

]]> Erreur : l'exposant $3$ multiplie l'écart, il ne le divise
pas. Les flottants sont d'autant plus espacés qu'ils sont
grands : $2^{-23} \times 2^{3} = 2^{-20}$.

]]> $2^{-29}$

]]> Erreur : les $32$ bits du codage ne sont pas tous des chiffres
de la mantisse. Seuls les $23$ bits de mantisse fixent la
précision : l'écart vaut $2^{3 - 23} = 2^{-20}$.

]]> Représentation des réels — Q33 : Trois fois un dixième Que vaut 0.1 * 3 == 0.3 en Python ?

]]> Tester l'égalité de deux flottants est presque toujours une erreur.
On compare plutôt leur écart à une tolérance.

]]> 1.0 0.0 0 true true abc False, le produit valant 0.30000000000000004

]]> Bonne réponse : ni $0{,}1$ ni $0{,}3$ ne sont représentables
exactement en binaire. Les erreurs ne se compensent pas et le
produit diffère de 0.3 au seizième chiffre.

]]> True, le calcul étant exact en décimal comme en binaire

]]> Erreur : 0.1 est déjà une approximation de $0{,}1$ ; la
multiplier par $3$ ne redonne pas l'approximation de $0{,}3$.

]]> Une erreur, un flottant ne pouvant être comparé avec ==

]]> Erreur : la comparaison est permise, elle est seulement peu
fiable.

]]> 0.3, la valeur commune des deux membres

]]> Erreur : une comparaison renvoie un booléen, et les deux membres
ne sont d'ailleurs pas égaux.

]]> Représentation des réels — Q34 : Une boucle qui ne rencontre jamais un Que se passe-t-il à l'exécution de ce programme ?

x = 0
while x != 1:
    x = x + 0.1
print("fini")

]]> Une boucle while sur un flottant doit utiliser < ou <=, jamais
!= ou == : l'égalité exacte n'est pas atteignable.

]]> 1.0 0.0 0 true true abc La boucle ne s'arrête jamais, x n'égalant jamais 1

]]> Bonne réponse : dix additions de 0.1 donnent
0.9999999999999999, puis x dépasse $1$ sans jamais l'égaler.
La condition reste vraie indéfiniment.

]]> Il affiche fini après dix tours, x valant alors exactement 1

]]> Erreur : après dix tours, x vaut 0.9999999999999999, pas
1.

]]> Il affiche fini après onze tours, x dépassant alors 1

]]> Erreur : au onzième tour x vaut environ 1.0999999999999999,
toujours différent de 1.

]]> Une erreur, != n'acceptant pas un entier et un flottant

]]> Erreur : la comparaison est valide ; le problème est qu'elle ne
devient jamais fausse.

]]> Représentation des réels — Q35 : Un entier qui n'est pas celui attendu Que vaut int((0.1 + 0.7) * 10) en Python ?

]]> Tronquer un flottant proche d'un entier est un piège classique :
round est plus sûr que int quand on attend une valeur entière.

]]> 1.0 0.0 0 true true abc 7, le produit valant 7.999999999999999

]]> Bonne réponse : 0.1 + 0.7 vaut 0.7999999999999999, un peu
moins que $0{,}8$ ; multiplié par $10$, le résultat reste sous
$8$, et int tronque à $7$.

]]> 8, le calcul tombant juste sur un entier

]]> Erreur : le calcul tombe juste en décimal, pas en binaire. Le
résultat est légèrement inférieur à $8$.

]]> 8.0, int conservant un flottant

]]> Erreur : int renvoie toujours un entier.

]]> Une erreur, int ne s'appliquant qu'aux chaînes

]]> Erreur : int accepte un flottant et le tronque.

]]> Représentation des réels — Q36 : Un affichage plus exact que la valeur stockée 0.1 n'est pas représentable exactement en binaire, et pourtant
print(0.1) affiche 0.1. Pourquoi ?

]]> L'affichage d'un flottant est une écriture décimale choisie pour
être courte et sans ambiguïté. Il ne dit rien de l'exactitude de
la valeur stockée.

]]> 1.0 0.0 0 true true abc Python affiche la plus courte écriture qui redonne le même flottant

]]> Bonne réponse : la valeur stockée est
$0{,}1000000000000000055\ldots$, mais 0.1 suffit à la
désigner sans ambiguïté, et c'est cette écriture courte qui est
affichée.

]]> Parce que 0.1 est stocké exactement, contrairement à 0.3

]]> Erreur : aucun des deux n'est exact ; $0{,}1$ est une fraction
dont le dénominateur n'est pas une puissance de $2$.

]]> Parce que print arrondit toujours à un chiffre après la virgule

]]> Erreur : print(0.30000000000000004) affiche bien dix-sept
chiffres ; l'arrondi dépend de ce qui suffit à retrouver la
valeur.

]]> Parce que l'erreur de représentation est corrigée à l'affichage

]]> Erreur : rien n'est corrigé, la valeur stockée reste inexacte ;
seule son écriture est raccourcie.

]]> Représentation des réels — Q37 : Combien de flottants entre un et deux En double précision, la mantisse compte $52$ bits après la virgule.
Combien de flottants distincts sont compris entre $1$ inclus et $2$
exclu ?

]]> Les flottants forment un ensemble fini et irrégulier : autant de
valeurs entre $1$ et $2$ qu'entre $1024$ et $2048$, mais bien plus
espacées dans le second cas.

]]> 1.0 0.0 0 true true abc $2^{52}$, un par mantisse possible

]]> Bonne réponse : entre $1$ et $2$, l'exposant est fixé à $0$ et
seule la mantisse varie, sur $52$ bits : $2^{52}$ valeurs,
régulièrement espacées de $2^{-52}$.

]]> Une infinité, comme pour les réels

]]> Erreur : un flottant occupe $64$ bits, donc il n'existe qu'un
nombre fini de valeurs, et une infinité de réels sont
inaccessibles.

]]> $2^{64}$, le nombre total de flottants

]]> Erreur : $2^{64}$ est le nombre de mots de $64$ bits, répartis
sur toutes les puissances de deux, pas seulement entre $1$ et
$2$.

]]> $1000$, un par millième entre les deux bornes

]]> Erreur : le pas des flottants n'est pas décimal ; entre $1$ et
$2$ il vaut $2^{-52}$, bien plus fin qu'un millième.

]]> Représentation des réels — Q38 : Pas et maximum d'une virgule fixe Un nombre est codé en virgule fixe sur $8$ bits, dont $4$ pour la
partie entière et $4$ pour la partie fractionnaire. Quel est
l'écart entre deux valeurs consécutives, et quelle est la plus
grande valeur codable ?

]]> En virgule fixe, le nombre de bits fractionnaires fixe la
précision, le nombre de bits entiers fixe la plage. Augmenter l'un
réduit l'autre : c'est la limite que lève la virgule flottante.

]]> 1.0 0.0 0 true true abc Un pas de $0{,}0625$ et un maximum de $15{,}9375$

]]> Bonne réponse : le dernier bit fractionnaire pèse $2^{-4} =
0{,}0625$, et le maximum, tous bits à $1$, vaut $2^{4} - 0{,}0625 =
15{,}9375$.

]]> Un pas de $0{,}25$ et un maximum de $15{,}9375$

]]> Erreur : le pas est le poids du bit le plus à droite,
$2^{-4}$, et non $1/4$.

]]> Un pas de $0{,}0625$ et un maximum de $16$

]]> Erreur : $16 = 2^{4}$ n'est pas codable : avec $4$
bits entiers, le maximum est $2^{4}$ moins un pas.

]]> Un pas de $1$ et un maximum de $255$

]]> Erreur : ce serait un entier non signé sur $8$ bits, sans partie
fractionnaire.

]]> Représentation des réels — Q39 : Une puissance de dix en Python Que vaut 1e3 en Python ?

]]> 3.5e-2 vaut $0{,}035$ et 6e23 vaut $6 \times 10^{23}$ : la
notation scientifique s'écrit avec e et produit un flottant.

]]> 1.0 0.0 0 true true abc 1000.0, un flottant

]]> Bonne réponse : 1e3 signifie $1 \times 10^{3}$ et cette
notation produit toujours un flottant, même pour une valeur
entière.

]]> 1000, un entier

]]> Erreur : la notation avec e donne un float, pas un int.

]]> 13

]]> Erreur : e ne concatène pas des chiffres, il introduit un
exposant de $10$.

]]> Une erreur, e n'étant pas un chiffre

]]> Erreur : 1e3 est une écriture valide, la notation scientifique
de Python.

]]> Représentation des réels — Q40 : Écrire un test d'égalité avec tolérance Quelle expression teste correctement que deux flottants a et b
sont égaux à $10^{-9}$ près ?

]]> Comparer des flottants, c'est comparer leur écart à un seuil ;
la valeur absolue évite le piège du signe.

]]> 1.0 0.0 0 true true abc abs(a - b) < 1e-9

]]> Bonne réponse : la valeur absolue rend le test symétrique, que
a soit un peu au-dessus ou un peu en dessous de b.

]]> abs(a) - abs(b) < 1e-9

]]> Erreur : ce test compare des valeurs absolues ; $-1$ et $1$
passeraient pour égaux.

]]> round(a) == round(b)

]]> Erreur : arrondir à l'entier confond $1{,}4$ et $0{,}6$.

]]> a == b ou a - b == 0

]]> Erreur : deux écritures du test exact, qui échoue sur
$0{,}1 + 0{,}2$.

]]> Représentation des réels — Q41 : Calculer des montants sans erreur d'arrondi Un programme de caisse additionne des prix en euros et des
centimes. Comment éviter les erreurs d'arrondi des flottants ?

]]> Dès qu'un calcul exige l'exactitude, argent, comptage, on choisit
une unité entière plutôt qu'un flottant.

]]> 1.0 0.0 0 true true abc Compter en centimes avec des entiers, exacts par nature

]]> Bonne réponse : $12{,}30$ € devient $1230$ centimes ; les
additions d'entiers sont exactes, et l'on ne divise par $100$
qu'à l'affichage.

]]> Arrondir le total à deux décimales après chaque addition

]]> Erreur : chaque arrondi corrige un peu, mais les erreurs
peuvent s'accumuler sur des milliers d'opérations.

]]> Utiliser des flottants en double précision, plus précis

]]> Erreur : les flottants de Python sont déjà en double précision,
et $0{,}1$ n'y est pas exact.

]]> Convertir chaque prix en chaîne avant de l'additionner

]]> Erreur : on ne peut pas additionner des chaînes.

]]> Représentation des réels — Q42 : Le bit caché de la mantisse Un flottant normalisé s'écrit $1{,}m \times 2^e$. Que devient le
$1$ placé avant la virgule dans le codage IEEE 754 ?

]]> Sous forme normalisée, le chiffre avant la virgule est toujours
$1$ en binaire : inutile de l'écrire, la norme le sous-entend.

]]> 1.0 0.0 0 true true abc Il n'est pas stocké, étant toujours égal à $1$

]]> Bonne réponse : seule la partie fractionnaire $m$ occupe les
bits de mantisse ; le $1$ est sous-entendu, ce qui gagne un bit
de précision.

]]> Il est stocké en tête des bits de mantisse

]]> Erreur : le stocker gaspillerait un bit toujours identique.

]]> Il vaut $0$ pour les nombres négatifs

]]> Erreur : le signe a son propre bit, la mantisse est la même.

]]> Il est ajouté à l'exposant

]]> Erreur : l'exposant ne code que la puissance de deux.

]]> Représentation des réels — Q43 : Le bit de signe d'un flottant Comment le signe d'un flottant est-il codé en IEEE 754 ?

]]> Signe, exposant, mantisse : les trois champs d'un flottant, le
premier ne prenant qu'un bit.

]]> 1.0 0.0 0 true true abc Par un seul bit, $1$ pour un nombre négatif

]]> Bonne réponse : le premier bit du codage vaut $0$ pour un
positif et $1$ pour un négatif ; mantisse et exposant codent la
valeur absolue.

]]> Par le complément à deux de la mantisse

]]> Erreur : le complément à deux concerne les entiers, pas les
flottants.

]]> Par un seul bit, $1$ pour un nombre positif

]]> Erreur : la convention est inverse, $1$ signale un négatif.

]]> Par le signe de l'exposant

]]> Erreur : l'exposant dit si le nombre est grand ou petit, pas
s'il est négatif.

]]>