Discussion :

[Array]

Bonjour,

Je lis un bouquin traitant de l'assembleur, en ce moment, écrit en anglais. Dans un des chapitre, l'auteur introduit le standard IEEE pour les nombres fractionnaires. À la fin dudit chapitre, il conclut en énonçant les étapes de la conversion d'un nombre au format IEEE:

To summarize, the following steps are used to convert a decimal number to
IEEE single format:
1. The leading bit of the floating point format is 0 for a positive number
and 1 for a negative number.
2. Write the unsigned number in binary.
3. Write the binary number in binary scientific notation f23.f22 ... f0 2^e,
where f23 = 1. There are 24 fraction bits, but it is not necessary to write
trailing 0's.
4. Add a bias of 127 to the exponent e. This sum, in binary form, is the
next 8 bits of the answer, following the sign bit. (Adding a bias is an
alternative to storing the exponent as a signed number.)
5. The fraction bits f22f21 ... f0 form the last 23 bits of the floating point
number. The leading bit f23 (which is always 1) is dropped.

Je ne comprend pas ce qu'il veut dire par

Adding a bias is an
alternative to storing the exponent as a signed number.

Est-ce qu'ajouter 127 est une autre façon de représenter des nombres signés, à l'instar du complément de deux, par exemple?

S.V.P. Éclairez moi!


COrdialement,

Array

[Obsidian]

Bonjour,

L'idée est d'utiliser a priori un nombre binaire signé ordinaire pour représenter l'exposant, jusque là d'accord, puis de lui ajouter 127. On note que si c'était 128, cela serait revenu à inverser le bit de signe.

C'est nécessaire à cause d'un petit souci technique développé ici : http://www.developpez.net/forums/d78...s/#post5479834

Et, de là, utiliser 127 plutôt que 128 permet de garder un intervalle symétrique de part et d'autre du zéro, tout en réservant la dernière valeur possible pour les valeurs spéciales telles que ±Inf, ou NaN.

[Array]

Obsidian, j'ai arrêté de comprende à

L'ennui vient du fait que « 2⁰ » se trouve en plein milieu de l'intervalle [2⁻¹²⁸;2⁺¹²⁷]. En introduisant le biais en question, on décale toutes ces valeurs de la moitié de l'intervalle et 2⁰ se retrouve tout en bas. « 00 00 00 00 » correspond alors au plus petit nombre positif représentable en simple précision. Les nombres dont l'exposant est plus bas que cela sortent des limites, sont trop proches du zéro et sont donc assimilés à zéro.

Il suffit donc d'ajouter « 00 00 00 00 » à ce dernier cas et de commencer l'intervalle des nombres représentables simplement un pas plus loin, intervalle qui a alors le mérite de rester continu.

Je ne comprend pas pourquoi tu dis que 2^0 est entre 2^-128 et 2^+127: 2^0 équivaut à un, alors que 2^-128 équivaut approximativement à 0 et 2^127 donne un très gros nombre... 1 est plus beaucoup beaucoup plus proche de 0 que de 2^127.

Si tu pouvais ré-expliquer, désolé de ce manque de compréhension, mais il est *très* important pour moi d'assimiler tout ceci, parce que beaucoup de mes programmes sont à saveur "mathématiques", donc j'tilise souvent "double", mais ne comprend pas toujours comment il fonctionne, ce qui me dérange.

Cordialement,

Array

[Obsidian]

Je ne comprend pas pourquoi tu dis que 2^0 est entre 2^-128 et 2^+127: 2^0 équivaut à un, alors que 2^-128 équivaut approximativement à 0 et 2^127 donne un très gros nombre... 1 est plus beaucoup beaucoup plus proche de 0 que de 2^127.

J'entends par là qu'il reste « au milieu de l'ensemble des nombres représentables ».

Si l'on décidait d'utiliser artificiellement « 00 00 00 00 » pour représenter le zéro sans introduire le biais, alors il faudrait sacrifier la valeur « 2⁰ ». Non seulement, cela reviendrait à se passer de « 1 », ce qui n'est pas concevable mais, en plus, on se retrouverait avec un intervalle troué : [2⁻¹²⁸;2⁻¹] ⋃ [2¹;2¹²⁷]. Enfin, plutôt [2⁻¹²⁸;2⁺¹²⁷] ∖ {2⁰}, puisqu'il faut tenir compte de la mantisse.

Si tu introduis le biais, la trame « 00 00 00 00 » représente automatiquement 1,0⋅2⁻¹²⁷, soit le plus petit nombre positif possible. Il se trouve donc tout en bas de l'intervalle et, si tu l'enlèves, tu conserves un intervalle continu. Et comme tout nombre à l'exposant plus petit que celui est automatiquement assimilé à zéro (parce qu'il est en dehors de l'intervalle), et bien il suffit de rajouter celui-ci.

Si tu pouvais ré-expliquer, désolé de ce manque de compréhension, mais il est *très* important pour moi d'assimiler tout ceci, parce que beaucoup de mes programmes sont à saveur "mathématiques", donc j'tilise souvent "double", mais ne comprend pas toujours comment il fonctionne, ce qui me dérange.

Comme expliqué dans les autres posts, les flottants IEEE 754 float et double fonctionnent sur le principe de la notation scientifique, tout simplement.

Sur les 32 bits d'un float, par exemple :

— Le premier bit décrit le signe (0 = +) ;
— Les huit bits suivants contiennent l'exposant signé, avec le biais ;
— Les vingt-trois bits restants représentent la mantisse.

Un flottant se calcule donc selon la formule : « 1,mantisse × 2^exposant ». L'exposant est une puissance de deux pour changer d'ordre de grandeur en binaire (formellement décaler de n colonnes à gauche ou à droite), de la même façon que l'on fait 1,xxx × 10^exposant en décimal, pour les mêmes raisons.

[Array]

J'ai compris le *pourquoi* du biais, mais la façon de le CPU le traite reste nébuleuse. Je m'explique.

Supposons que je souhaite représenter 4.5 en binaire,
ça fait:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
100.1 = 1.001 x 2^e
ici, e = 2
 
EN stockant en float, l'exposant interne et la mantisse deviennent:
exposant_ieee=e+127=2+127=129
mantisse_ieee=001
 
De fait, en interne, ça devient 1.001 x 2^129

Je suppose que quand, par exemple, je fais l'opération "4.5 x 2.5", les biais sont soustraits des exposants respectifs, puis lesdits exposants sont additionnés ensemble - puisque c'est une multiplication, les exposants sont additionnés, es parties entières respectives étant, tant qu'à elles, multipliées entre elles -, puis ajoute 127 au résultat de cette somme, et on le stocke dans les 8 bits réservés à l'exposant, est-ce exact?
Sinon, comment fait-on pour que le biais de 127 n'affecte pas les résultats lors des opérations arithmétiques?

De même, les exposants pouvant être représentés fidèlement, sans interprétation, vont de -126 à 127? -127 et -128 étant réservés?


Merci,

Array

[Obsidian]

Je suppose que quand, par exemple, je fais l'opération "4.5 x 2.5", les biais sont soustraits des exposants respectifs, puis lesdits exposants sont additionnés ensemble - puisque c'est une multiplication, les exposants sont additionnés, es parties entières respectives étant, tant qu'à elles, multipliées entre elles -, puis ajoute 127 au résultat de cette somme, et on le stocke dans les 8 bits réservés à l'exposant, est-ce exact?

Tout-à-fait.

Si c'est ça qui t'ennuyait dès le départ, d'ailleurs, la phrase « Adding a bias is an
alternative to storing the exponent as a signed number » ne veut rien dire de plus que ce qu'elle dit déjà : « Ajouter un biais est une alternative au stockage de l'exposant en tant que nombre signé », dans le sens « c'est une autre manière de faire ». Rien de plus.

De même, les exposants pouvant être représentés fidèlement, sans interprétation, vont de -126 à 127? -127 et -128 étant réservés?

C'est cela aussi. En fait, en pratique, l'exposant peut être vu comme un nombre binaire naturel entier NON signé cette fois, courant de 0 (00000000) à 255 (11111111). Ces deux valeurs extrêmes sont réservées pour coder les nombres spéciaux.

Compte tenu du biais, 0 correspondrait à e⁻¹²⁷ et 255 à e⁺¹²⁸, donc les exposants des nombres normalisés courent bien de 2⁻¹²⁶ à 2⁺¹²⁷.

Le tableau suivant récapitule ces quelques exceptions : http://fr.wikipedia.org/wiki/IEEE_754#Exceptions

Donc, en gros, les exposants réservés avec une mantisse nulle correspondent soit au zéro, soit à l'infini. Ceux avec une mantisse non nulle correspondent soit aux nombres dénormalisés, soit aux NaN.

Les nombres dénormalisés fonctionnent comme les autres sauf qu'ils représentent 0,mantisse plutôt que 1,mantisse, mais comme leur exposant est fixe, il n'y a pas de risque de coder une même valeur de deux façons différentes. Cela permet donc de descendre jusqu'à 52 bits en dessous de la valeur minimum théorique, pour un double.

[Array]

Tout-à-fait.

Excellent!

Dernière question. Maintenant que je comprend comment sont faites la multiplication et la division - puisque cette dernière est en tout point sembable à la multiplication -, qu'en est il de l'addition?

Est-ce que, par example, quand je fais "2.5 + 4.75", le programme additionne d'abord les parties fractionnaires ".1 + .11 = 1.01", retient une éventuelle partie entière découlant de cette addition (ici 1), l'ajoute à l'addition des deux parties entières appartenant aux nombres additionnés, puis recalcule l'exposant? Dans ce cas, contrairement à la multiplication, aucun arithmétique est effectué sur l'exposant, il est juste recalculé, correct?


Cordialement,

Array

[Obsidian]

Est-ce que, par example, quand je fais "2.5 + 4.75", le programme additionne d'abord les parties fractionnaires ".1 + .11 = 1.01", retient une éventuelle partie entière découlant de cette addition (ici 1), l'ajoute à l'addition des deux parties entières appartenant aux nombres additionnés, puis recalcule l'exposant? Dans ce cas, contrairement à la multiplication, aucun arithmétique est effectué sur l'exposant, il est juste recalculé, correct?

Pas tout-à-fait, 2.5 et 4.75 s'écrivent respectivement 10.1 et 100.11 en binaire, soit 1,01⋅e¹ et 1.0011⋅e².. Puisqu'on pose le premier « 1 », les mantisses de ces nombres sont .01 et .0011.

Ensuite, lorsque tu additionnes, tu es obligé de travailler sur un même ordre de grandeur. On décale donc vers la droite les bits du nombre dont l'exposant est le plus petit pour ramener celui-ci au même degré que l'autre, ce qui peut avoir pour effet de les faire sortir complètement si l'écart entre les deux est supérieur à la taille de la mantisse. Par exemple, tu ne peux pas faire 1.000.000.000 + 1 sur un float 32 bits. Le « 1 » est négligé et assimilé à zéro.

En l'occurrence, on va choisir e² et additionner 0,101 et 1,0011. Note que le « 1 » en gras est le bit implicite qu'il a fallu faire entrer dans la mantisse. De là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
   0,101
 + 1,0011
-----------
   1,1101

On obtient donc la mantisse finale. Pour vérifier, comme on a un exposant 2, on décale deux fois la virgule vers la droite, ce qui donne « 111,01 », ce qui est bien égal à 7,25, donc à 2,5 + 4,75.

On note que si l'on additionne deux nombres de n bits, on obtient un résultat d'un plus n+1 bits. Pour additionner les deux mantisses, comme elles sont déjà alignées à droite du champ de bits, il suffirait donc de faire un masque ET pour les extraire directement et les additionner dans la foulée. Mais pour la raison que je viens de citer, beaucoup d'implémentations préfèrent les aligner à gauche du champ. D'abord parce que c'est cohérent étant donné leur position par rapport à la virgule, mais également parce que le bit supplémentaire se retrouve dans le bit C (la retenue du micro-processeur) et qu'à ce moment, il suffit de l'ajouter à l'exposant final.

[Array]

Hmm, je comprend parfaitement. Cette dernière réponse a aiguisé ma curiosité à propos de deux autres sujets...

La division, comment s'effectue-t-elle? Je vais tenter de deviner...
Je suppose que si, par exemple, que si je divise 101.101 (5.625) par 10.01 (2.25), on fait la division de 101101/1001 ce qui donne 101 (5). Ensuite, on soustrait les exposants respectifs desquels on a soustrait le biais (2 - 1), et on donne ce même exposant au résultat, soit 1.01 x 2^1, ce qui donne effectivement le résultat, soit 2.5, ou 10.1. Est-ce exact? Ou est-ce qu'il y a des pécularités?


Aussi, j'aimerais bien savoir comment les approximations pour convertir le développement fractionnaire des nombres décimaux en nombres binaires sont faites, lorsqu'on approxime la mantisse. Si c'est trop compliqué à expliquer ici, y-aurait-il de la doc par hazard? Par exemple, quand on essaie de convertier 2.8 en binaire, il doit y avoir une approximation, puisque .8 ne peut parfaitement être représenté en binaire, exact?

Merci beacoup!

Cordialement,

Array

[Obsidian]

Je suppose que si, par exemple, que si je divise 101.101 (5.625) par 10.01 (2.25), on fait la division de 101101/1001 ce qui donne 101 (5). Ensuite, on soustrait les exposants respectifs desquels on a soustrait le biais (2 - 1), et on donne ce même exposant au résultat, soit 1.01 x 2^1, ce qui donne effectivement le résultat, soit 2.5, ou 10.1. Est-ce exact? Ou est-ce qu'il y a des pécularités?

C'est globalement exact mais il y a quand même des particularités dont il faut tenir compte au moment où l'on rédige la routine qui fait ces calculs (lorsqu'ils ne sont pas confiés à un coprocesseur mathématique). La principale est la position des bits.

Ici, tu considères les valeurs de tes mantisses comme des nombres entiers, ce qui est justement une forme de réajustement. Il faudra donc en tenir compte dans le calcul de tes exposants.

Tu devrais être capable de trouver tout seul, de toutes façons : tu as dit que tu divisais 101101 par 1001. Comment vas-tu t'y prendre pour ce faire ?

Aussi, j'aimerais bien savoir comment les approximations pour convertir le développement fractionnaire des nombres décimaux en nombres binaires sont faites, lorsqu'on approxime la mantisse. Si c'est trop compliqué à expliquer ici, y-aurait-il de la doc par hazard? Par exemple, quand on essaie de convertier 2.8 en binaire, il doit y avoir une approximation, puisque .8 ne peut parfaitement être représenté en binaire, exact?

Absolument. J'avoue bien humblement que je ne le sais pas par cœur. Le meilleur endroit, à mon avis, est la norme IEEE 754 officielle. Bien qu'on n'ait pas attendu cette norme pour utiliser des nombres flottants, la manière de traiter ces approximations dans le cadre de nombres ainsi normalisés est forcément détaillée dedans de façon explicite.

Cela dit, la première chose que l'on fait lorsqu'on produit un flottant, on arrondit de la même façon qu'en décimal. Sur papier, lorsque le chiffre le plus à droite sortant de la mantisse est entre 0 et 4 on arrondit par défaut ; lorsqu'il est entre 5 et 9. On arrondit par excès. Donc 1623 ≈ 1,62⋅10³ et 1627 ≈ 1,63⋅10³. En binaire, comme il n'y a que deux chiffres, il suffit d'incrémenter le résultat si le bit sortant vaut 1, donc.

Après, les façons d'arrondir et les comportements à adopter sont en général définis de façon claire par les langages que tu utilises. En C, par exemple, le fichier d'entête « float.h » contient toutes les définitions nécessaires.

En particulier, le plus petit nombre plus grand que 1, c'est-à-dire celui qui correspond au bit le plus à droite de ta mantisse, est noté ε et est défini pour chaque type, sous la forme de constantes symboliques telle que FLT_EPSILON, DBL_EPSILON, etc.

Pour décider d'arrondir, il faut donc choisir la puissance de 10 la plus proche à ε ÷ 2 près.

[Obsidian]

UPDATE : Je me rends compte que mon dernier paragraphe ne répond pas totalement à la question soulevée. J'ai donc fait quelques tests.

En C, il semblerait que la précision décimale par défaut soit fixée à six chiffres après la virgule, modifiable avec les paramètres de printf(). La valeur « 2.6 » respectivement au format double puis float donne les résultats suivants, avec le code suivant en langage C :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <stdio.h>
 
int main (void)
{
    printf ("%f\n",2.6);
    printf ("%1.3f\n",2.6);
    printf ("%1.6f\n",2.6);
    printf ("%1.8f\n",2.6);
    printf ("%1.10f\n",2.6);
    printf ("%1.12f\n",2.6);
    printf ("%1.14f\n",2.6);
    printf ("%1.16f\n",2.6);
    printf ("%1.18f\n",2.6);
 
    puts ("");
 
    printf ("%f\n",(float)2.6F);
    printf ("%1.3f\n",(float)2.6);
    printf ("%1.6f\n",(float)2.6);
    printf ("%1.8f\n",(float)2.6);
    printf ("%1.10f\n",(float)2.6);
    printf ("%1.12f\n",(float)2.6);
    printf ("%1.14f\n",(float)2.6);
    printf ("%1.16f\n",(float)2.6);
    printf ("%1.18f\n",(float)2.6);
 
    return 0;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2.600000
2.600
2.600000
2.60000000
2.6000000000
2.600000000000
2.60000000000000
2.6000000000000001
2.600000000000000089
 
2.600000
2.600
2.600000
2.59999990
2.5999999046
2.599999904633
2.59999990463257
2.5999999046325684
2.599999904632568359

Un programme écrit sur mesure, n'effectuant aucun arrondi et calculant lui-même la représentation décimale donne ceci, pour chaque type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
2.599999904632568359375
2.600000000000000088817841970012523233890533447265625

… soit un nombre légèrement supérieur dans le cas de double et inférieur pour float.

Il semblerait donc bien que la routine de conversion extrait chacune de ses décimales (dans la base d'arrivée) jusqu'à une position donnée, examine la suivante, fasse le choix d'incrémenter le résultat déjà calculé dans le cas d'un arrondi par excès.

Cela dit, pour ce faire, il n'y a pas besoin de refaire un calcul. Il suffit de retenir la valeur et la position de la dernière décimale différente de 9 (ou d'une manière générale, du complément de zéro) et de choisir le chiffre suivant en cas d'arrondi. On termine donc en posant cette dernière décimale, et en remplissant éventuellement avec des « 0 » ou avec des « 9 » selon l'arrondi effectué.