$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.

]]> int

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

]]> 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.

]]> 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 × 2ᵉ, 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 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.

]]> 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).

]]> Un signe et une valeur absolue

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

]]> Une fraction irréductible

]]> Une fraction irréductible
(comme 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.

]]> 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 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.

]]> 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.

]]> 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.

]]> Le format des adresses IP

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

]]> 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 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 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.

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

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

]]> 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 π, √2) doivent être
approchés. Même certains nombres « simples » comme
0{,}1 n'ont pas de représentation binaire finie.

]]> 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.

]]> 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.

]]> 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.

]]> 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 abs(a - b) < epsilon

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

]]> 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.

]]> a == b

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

]]> 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⁻³⁰⁰) à très
grand (10³⁰⁰), au prix d'une précision relative.

]]> 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).

]]> Aucune différence en pratique

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

]]> 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).

]]> 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.

]]> 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.

]]> 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.

]]> 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 ½,
¼, ⅛, 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{,}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.

]]> 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{,}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à.

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

``python
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 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.

]]> 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.

]]> 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.

]]> 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.

]]> 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.

]]> 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.

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

`python
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 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.

]]> 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.

]]> 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é.

]]> 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
½, ¼, ⅛ 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{,}5

]]> Erreur : 0{,}01_2 n'est pas un demi. Chaque rang après la
virgule a son poids, ½, ¼, ⅛,
d'où 0{,}25.

]]> 3{,}25

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

]]> 6{,}01

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

]]> 6{,}25

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

]]> 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 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 nombres complexes en Python

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

]]> Utiliser des float

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

]]> 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' (chaîne de caractères)

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

]]> 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.

]]> 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¹⁶ pour la mantisse

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

]]> C'est un bug de Python

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

]]> 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.

]]> Parce que Python ne sait pas additionner

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

]]> 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 m × 10ᵉ 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 × 2ᵉ).

]]> 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}.

]]> 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.

]]> 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.

]]> 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.

]]> Cela dépend du langage de programmation

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

]]> 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 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.

]]> 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é.

]]> 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 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.

]]> 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.

]]> Représentation des réels — Q24 : Une tolérance mal dimensionnée Sarah compare deux flottants avec une tolérance fixe :
``python
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⁻⁹ convient pour des valeurs proches de 1,
mais tout écart entre des valeurs de l'ordre de 10⁻¹²
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 Le test est correct, car deux flottants qui diffèrent de moins de 10⁻⁹ 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⁻¹⁶. C'est le seuil choisi
par Sarah qui est inadapté, pas la représentation.

]]> La tolérance 10⁻⁹ est énorme devant les valeurs comparées, il faut l'adapter à leur ordre de grandeur

]]> Bonne réponse : l'écart réel vaut 10⁻¹², 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⁻³⁰⁸, bien en dessous de 10⁻¹². 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.

]]> 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 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.

]]> 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.

]]> 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 110{,}101

]]> Bonne réponse : la partie entière donne 6 = 110₂. 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.

]]> 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.

]]> 1010{,}101

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

]]> 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.

]]> 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 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 × 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{,}5

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

]]> 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{,}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{,}25

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

]]> 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 10000010₂

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

]]> 01111101₂

]]> Erreur : 01111101₂ = 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.

]]> 00000010₂

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

]]> 10000001₂

]]> Bonne réponse : l'exposant stocké est 2 + 127 = 129 = 128 + 1, ce
qui s'écrit 10000001₂ 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₂ = 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² = 4, pas 2³ = 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.

]]> 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.

]]> 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.

]]> 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⁵, 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 00000000101₂

]]> 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.

]]> 00010000100₂

]]> 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.

]]> 01111111010₂

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

]]> 10000000100₂

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

]]> 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³ et
2⁴ 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⁻²³ fois la puissance de deux de
l'intervalle. Près de 1, les flottants sont espacés d'environ
10⁻⁷ ; près de 10⁶, d'environ 0{,}06.

]]> 1.0 0.0 0 true true abc 2⁻²⁹

]]> 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}.

]]> 2⁻²⁶

]]> 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⁻²³ × 2³ = 2⁻²⁰.

]]> 2⁻²⁰

]]> 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⁻²³. Deux flottants consécutifs diffèrent donc de
2⁻²³ × 2³ = 2⁻²⁰.

]]> 2⁻²¹

]]> 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⁻²³, d'où un écart de 2⁻²⁰.

]]> 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.

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

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

]]> 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.

]]> 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 ?
`python
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 Il affiche fini après dix tours, x valant alors exactement 1

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

]]> 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.

]]> 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.

]]> 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.

]]> 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 Une erreur, int ne s'appliquant qu'aux chaînes

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

]]> 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.

]]> 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.0, int conservant un flottant

]]> Erreur : int renvoie toujours un entier.

]]> 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 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.

]]> 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 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.

]]> 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⁶⁴, le nombre total de flottants

]]> Erreur : 2⁶⁴ 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⁻⁵², bien plus fin qu'un millième.

]]> 2⁵², 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⁵² valeurs,
régulièrement espacées de 2⁻⁵².

]]> 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.

]]> 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 16

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

]]> 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⁻⁴, et non 1/4.

]]> 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 × 10²³ : la
notation scientifique s'écrit avec e et produit un flottant.

]]> 1.0 0.0 0 true true abc 13

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

]]> 1000.0, un flottant

]]> Bonne réponse : 1e3 signifie 1 × 10³ et cette
notation produit toujours un flottant, même pour une valeur
entière.

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

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

]]> 1000, un entier

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

]]> 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⁻⁹ 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 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.

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

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

]]> 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.

]]> 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 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.

]]> 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.

]]> 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 est ajouté à l'exposant

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

]]> 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 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.

]]> 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 le signe de l'exposant

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

]]> 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.

]]>