Dans l'article <4bb3886a$0$20650$,
Samuel DEVULDER écrit:Peut-etre.. qu'est il préconisé à la place? Parce que les codes pour
parser la partie fractionnaire où l'on trouve:
double b = 0.1;
while(..) {
x += ((*s++) - '0') * b;
b /= 10;
}
sont légions et contiennent tous le même bug.
Ce code est mauvais. Pour bien faire, de la multiprécision est
nécessaire (e.g. en entier ou avec rationnels exacts).
Dans notre "Handbook of Floating-Point Arithmetic", on donne justement
un tel algorithme de conversion, en fait base 2 - base 10 (algo 2.2
page 45).
Le code est tout de même faux sur la plupart des machines actuelles
(avec des long sur 64 bits)!Hum? Je ne vois pas. D'un coté tu as 2 long int à 32 bits chacun, et de
l'autre 64bits. Ca doit rentrer.
Relis ce que je dis: je parle de long sur 64 bits (cas le plus courant
sur machines 64 bits).
Dans l'article <4bb3886a$0$20650$426a74cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> écrit:
Peut-etre.. qu'est il préconisé à la place? Parce que les codes pour
parser la partie fractionnaire où l'on trouve:
double b = 0.1;
while(..) {
x += ((*s++) - '0') * b;
b /= 10;
}
sont légions et contiennent tous le même bug.
Ce code est mauvais. Pour bien faire, de la multiprécision est
nécessaire (e.g. en entier ou avec rationnels exacts).
Dans notre "Handbook of Floating-Point Arithmetic", on donne justement
un tel algorithme de conversion, en fait base 2 - base 10 (algo 2.2
page 45).
Le code est tout de même faux sur la plupart des machines actuelles
(avec des long sur 64 bits)!
Hum? Je ne vois pas. D'un coté tu as 2 long int à 32 bits chacun, et de
l'autre 64bits. Ca doit rentrer.
Relis ce que je dis: je parle de long sur 64 bits (cas le plus courant
sur machines 64 bits).
Dans l'article <4bb3886a$0$20650$,
Samuel DEVULDER écrit:Peut-etre.. qu'est il préconisé à la place? Parce que les codes pour
parser la partie fractionnaire où l'on trouve:
double b = 0.1;
while(..) {
x += ((*s++) - '0') * b;
b /= 10;
}
sont légions et contiennent tous le même bug.
Ce code est mauvais. Pour bien faire, de la multiprécision est
nécessaire (e.g. en entier ou avec rationnels exacts).
Dans notre "Handbook of Floating-Point Arithmetic", on donne justement
un tel algorithme de conversion, en fait base 2 - base 10 (algo 2.2
page 45).
Le code est tout de même faux sur la plupart des machines actuelles
(avec des long sur 64 bits)!Hum? Je ne vois pas. D'un coté tu as 2 long int à 32 bits chacun, et de
l'autre 64bits. Ca doit rentrer.
Relis ce que je dis: je parle de long sur 64 bits (cas le plus courant
sur machines 64 bits).
Aussi après un appel de rint...pour savoir si un nombre est un entier ou pas?
Non, pour convertir en entier parce que dans telle formule, c'est ce
qu'on a. Si l'erreur était < 0.5, alors on obtient le vrai résultat
(exact).
Pourquoi donc? tous les doubles sont sérialisés en mémoire de la même
façon au format IEEE.
Il y a d'une part les 0 signés: dans la pratique, on veut généralement
que +0 et -0 soient considérés comme la même valeur (et d'ailleurs,
+0.0 == -0.0 en C). D'autre part, si le but est aussi de considérer
deux NaN comme égaux, l'encodage des NaN n'est pas complètement
normalisé, cf le payload.
Et puis il y a de toute façon le problème de performance: un test
d'égalité n'a pas besoin d'avoir à faire passer des registres
flottants dans des registres entiers via la mémoire.
Aussi après un appel de rint...
pour savoir si un nombre est un entier ou pas?
Non, pour convertir en entier parce que dans telle formule, c'est ce
qu'on a. Si l'erreur était < 0.5, alors on obtient le vrai résultat
(exact).
Pourquoi donc? tous les doubles sont sérialisés en mémoire de la même
façon au format IEEE.
Il y a d'une part les 0 signés: dans la pratique, on veut généralement
que +0 et -0 soient considérés comme la même valeur (et d'ailleurs,
+0.0 == -0.0 en C). D'autre part, si le but est aussi de considérer
deux NaN comme égaux, l'encodage des NaN n'est pas complètement
normalisé, cf le payload.
Et puis il y a de toute façon le problème de performance: un test
d'égalité n'a pas besoin d'avoir à faire passer des registres
flottants dans des registres entiers via la mémoire.
Aussi après un appel de rint...pour savoir si un nombre est un entier ou pas?
Non, pour convertir en entier parce que dans telle formule, c'est ce
qu'on a. Si l'erreur était < 0.5, alors on obtient le vrai résultat
(exact).
Pourquoi donc? tous les doubles sont sérialisés en mémoire de la même
façon au format IEEE.
Il y a d'une part les 0 signés: dans la pratique, on veut généralement
que +0 et -0 soient considérés comme la même valeur (et d'ailleurs,
+0.0 == -0.0 en C). D'autre part, si le but est aussi de considérer
deux NaN comme égaux, l'encodage des NaN n'est pas complètement
normalisé, cf le payload.
Et puis il y a de toute façon le problème de performance: un test
d'égalité n'a pas besoin d'avoir à faire passer des registres
flottants dans des registres entiers via la mémoire.
Samuel DEVULDER a écrit :Vincent Lefevre a écrit :On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)C'est quoi ces zéros de têtes..
Samuel DEVULDER a écrit :
Vincent Lefevre a écrit :
On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)
C'est quoi ces zéros de têtes..
Samuel DEVULDER a écrit :Vincent Lefevre a écrit :On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)C'est quoi ces zéros de têtes..
compilés avec le snapshot de GCC. La solution est de passer par
une union (ou un tableau d'unsigned char).
compilés avec le snapshot de GCC. La solution est de passer par
une union (ou un tableau d'unsigned char).
compilés avec le snapshot de GCC. La solution est de passer par
une union (ou un tableau d'unsigned char).
Dans l'article ,
Jean-Marc Bourguet écrit:
> - on ne lit pas le dernier membre écrit dans l'union, à nouveau non
> conforme.
C'est autorisé par la norme C (ce qui ne l'est pas, c'est de faire
le même genre de chose via des pointeurs), mais partiellement du
domaine de l'implementation-defined.
Dans l'article <87iq8cs6al.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
> - on ne lit pas le dernier membre écrit dans l'union, à nouveau non
> conforme.
C'est autorisé par la norme C (ce qui ne l'est pas, c'est de faire
le même genre de chose via des pointeurs), mais partiellement du
domaine de l'implementation-defined.
Dans l'article ,
Jean-Marc Bourguet écrit:
> - on ne lit pas le dernier membre écrit dans l'union, à nouveau non
> conforme.
C'est autorisé par la norme C (ce qui ne l'est pas, c'est de faire
le même genre de chose via des pointeurs), mais partiellement du
domaine de l'implementation-defined.
Vincent Lefevre a écrit :
> compilés avec le snapshot de GCC. La solution est de passer par
Heureusement qu'il n'y a pas que GCC dans le marché (même pas fichu de
faire du code VLE sur MPC55xx, ou de compiler sans manquer de registres sur
la gamme issue des 68xx).
> une union (ou un tableau d'unsigned char).
Vincent Lefevre a écrit :
> compilés avec le snapshot de GCC. La solution est de passer par
Heureusement qu'il n'y a pas que GCC dans le marché (même pas fichu de
faire du code VLE sur MPC55xx, ou de compiler sans manquer de registres sur
la gamme issue des 68xx).
> une union (ou un tableau d'unsigned char).
Vincent Lefevre a écrit :
> compilés avec le snapshot de GCC. La solution est de passer par
Heureusement qu'il n'y a pas que GCC dans le marché (même pas fichu de
faire du code VLE sur MPC55xx, ou de compiler sans manquer de registres sur
la gamme issue des 68xx).
> une union (ou un tableau d'unsigned char).
Question 3 : y a-t-il un équivalent des notations fixe, scientifique, et
ingénérie (%f, %e et %g)
%a est l'équivalent de %e (mais la précision par défaut n'est pas figée
à 6, elle est plutôt « la bonne valeur » (pour avoir une représentation
avec toute l'expressivité possible); il n'y a pas d'équivalent de %f ou
%g (dont je ne vois pas le rapport avec l'ingénierie, c'est juste un
format plus élaboré qui combine %e et %f).
Question 3 : y a-t-il un équivalent des notations fixe, scientifique, et
ingénérie (%f, %e et %g)
%a est l'équivalent de %e (mais la précision par défaut n'est pas figée
à 6, elle est plutôt « la bonne valeur » (pour avoir une représentation
avec toute l'expressivité possible); il n'y a pas d'équivalent de %f ou
%g (dont je ne vois pas le rapport avec l'ingénierie, c'est juste un
format plus élaboré qui combine %e et %f).
Question 3 : y a-t-il un équivalent des notations fixe, scientifique, et
ingénérie (%f, %e et %g)
%a est l'équivalent de %e (mais la précision par défaut n'est pas figée
à 6, elle est plutôt « la bonne valeur » (pour avoir une représentation
avec toute l'expressivité possible); il n'y a pas d'équivalent de %f ou
%g (dont je ne vois pas le rapport avec l'ingénierie, c'est juste un
format plus élaboré qui combine %e et %f).
Antoine Leca a écrit :Samuel DEVULDER a écrit :Vincent Lefevre a écrit :On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)C'est quoi ces zéros de têtes..
En fait les zeros de têtes sont les *bits* à zero qu'on décide de placer
dans la partie avant le point.
Punaise. Zero et bit à zero c'est pas pareil! Sans déconner ca aide pas
à comprendre.. moi je parlais des zéros hexa en fin de nombre et d'un
autre coté on parle de bit à zero au début, tout cela en parlant de zéro
comme si il n'y avait qu'un seul zéro. Pas facile!
Ok c'est plus clair à présent, sauf que je ne vois pas pourquoi on a
laissé un choix arbitraire pour ce 1er digit. On aurait pris le 1
universel (c'est le même dans toutes les bases), et toujours là dans le
cadre flottant IEEE (sauf pour le vrai zero), on aurait eu une seule
façon de représenter un nombre et je pense que ca n'aurait pas changé
grand chose aux routines de printf/scanf (voir ca les aurait simplifiées).
Il n'y a pas de raison de grouper le 1er digit en 4 ou 1 bit.. de toute
façon la base de l'exponentielle est 2 (p=pow(2,.)), donc ca signifie
qu'on travaille avec un alignement de 1bit fondamentalement. Je dis pas,
si on avait dit que p signifiait 16, alors là oui ca aurait eu du sens
de dire que le 1er digit est dans 0..9a..f.. mais avec un alignement au
bit près, on aurait dit que c'était toujours le digit de poids fort,
j'aurais trouvé ca super logique. Mais bon on a peut être voulu faire
plaisir à ceux qui voulaient que M_PI commence par un 3 aussi quand il
est représenté en flottant base 16.
sam (bits à zéro, tête à toto!)
Antoine Leca a écrit :
Samuel DEVULDER a écrit :
Vincent Lefevre a écrit :
On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)
C'est quoi ces zéros de têtes..
En fait les zeros de têtes sont les *bits* à zero qu'on décide de placer
dans la partie avant le point.
Punaise. Zero et bit à zero c'est pas pareil! Sans déconner ca aide pas
à comprendre.. moi je parlais des zéros hexa en fin de nombre et d'un
autre coté on parle de bit à zero au début, tout cela en parlant de zéro
comme si il n'y avait qu'un seul zéro. Pas facile!
Ok c'est plus clair à présent, sauf que je ne vois pas pourquoi on a
laissé un choix arbitraire pour ce 1er digit. On aurait pris le 1
universel (c'est le même dans toutes les bases), et toujours là dans le
cadre flottant IEEE (sauf pour le vrai zero), on aurait eu une seule
façon de représenter un nombre et je pense que ca n'aurait pas changé
grand chose aux routines de printf/scanf (voir ca les aurait simplifiées).
Il n'y a pas de raison de grouper le 1er digit en 4 ou 1 bit.. de toute
façon la base de l'exponentielle est 2 (p=pow(2,.)), donc ca signifie
qu'on travaille avec un alignement de 1bit fondamentalement. Je dis pas,
si on avait dit que p signifiait 16, alors là oui ca aurait eu du sens
de dire que le 1er digit est dans 0..9a..f.. mais avec un alignement au
bit près, on aurait dit que c'était toujours le digit de poids fort,
j'aurais trouvé ca super logique. Mais bon on a peut être voulu faire
plaisir à ceux qui voulaient que M_PI commence par un 3 aussi quand il
est représenté en flottant base 16.
sam (bits à zéro, tête à toto!)
Antoine Leca a écrit :Samuel DEVULDER a écrit :Vincent Lefevre a écrit :On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)C'est quoi ces zéros de têtes..
En fait les zeros de têtes sont les *bits* à zero qu'on décide de placer
dans la partie avant le point.
Punaise. Zero et bit à zero c'est pas pareil! Sans déconner ca aide pas
à comprendre.. moi je parlais des zéros hexa en fin de nombre et d'un
autre coté on parle de bit à zero au début, tout cela en parlant de zéro
comme si il n'y avait qu'un seul zéro. Pas facile!
Ok c'est plus clair à présent, sauf que je ne vois pas pourquoi on a
laissé un choix arbitraire pour ce 1er digit. On aurait pris le 1
universel (c'est le même dans toutes les bases), et toujours là dans le
cadre flottant IEEE (sauf pour le vrai zero), on aurait eu une seule
façon de représenter un nombre et je pense que ca n'aurait pas changé
grand chose aux routines de printf/scanf (voir ca les aurait simplifiées).
Il n'y a pas de raison de grouper le 1er digit en 4 ou 1 bit.. de toute
façon la base de l'exponentielle est 2 (p=pow(2,.)), donc ca signifie
qu'on travaille avec un alignement de 1bit fondamentalement. Je dis pas,
si on avait dit que p signifiait 16, alors là oui ca aurait eu du sens
de dire que le 1er digit est dans 0..9a..f.. mais avec un alignement au
bit près, on aurait dit que c'était toujours le digit de poids fort,
j'aurais trouvé ca super logique. Mais bon on a peut être voulu faire
plaisir à ceux qui voulaient que M_PI commence par un 3 aussi quand il
est représenté en flottant base 16.
sam (bits à zéro, tête à toto!)
Antoine Leca a écrit :Samuel DEVULDER a écrit :Vincent Lefevre a écrit :On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)C'est quoi ces zéros de têtes..
En fait les zeros de têtes sont les *bits* à zero qu'on décide de placer
dans la partie avant le point.
Punaise. Zero et bit à zero c'est pas pareil! Sans déconner ca aide pas
à comprendre.. moi je parlais des zéros hexa en fin de nombre et d'un
autre coté on parle de bit à zero au début, tout cela en parlant de zéro
comme si il n'y avait qu'un seul zéro. Pas facile!
Ok c'est plus clair à présent, sauf que je ne vois pas pourquoi on a
laissé un choix arbitraire pour ce 1er digit. On aurait pris le 1
universel (c'est le même dans toutes les bases), et toujours là dans le
cadre flottant IEEE (sauf pour le vrai zero), on aurait eu une seule
façon de représenter un nombre et je pense que ca n'aurait pas changé
grand chose aux routines de printf/scanf (voir ca les aurait simplifiées).
Il n'y a pas de raison de grouper le 1er digit en 4 ou 1 bit.. de toute
façon la base de l'exponentielle est 2 (p=pow(2,.)), donc ca signifie
qu'on travaille avec un alignement de 1bit fondamentalement. Je dis pas,
si on avait dit que p signifiait 16, alors là oui ca aurait eu du sens
de dire que le 1er digit est dans 0..9a..f.. mais avec un alignement au
bit près, on aurait dit que c'était toujours le digit de poids fort,
j'aurais trouvé ca super logique. Mais bon on a peut être voulu faire
plaisir à ceux qui voulaient que M_PI commence par un 3 aussi quand il
est représenté en flottant base 16.
sam (bits à zéro, tête à toto!)
Antoine Leca a écrit :
Samuel DEVULDER a écrit :
Vincent Lefevre a écrit :
On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)
C'est quoi ces zéros de têtes..
En fait les zeros de têtes sont les *bits* à zero qu'on décide de placer
dans la partie avant le point.
Punaise. Zero et bit à zero c'est pas pareil! Sans déconner ca aide pas
à comprendre.. moi je parlais des zéros hexa en fin de nombre et d'un
autre coté on parle de bit à zero au début, tout cela en parlant de zéro
comme si il n'y avait qu'un seul zéro. Pas facile!
Ok c'est plus clair à présent, sauf que je ne vois pas pourquoi on a
laissé un choix arbitraire pour ce 1er digit. On aurait pris le 1
universel (c'est le même dans toutes les bases), et toujours là dans le
cadre flottant IEEE (sauf pour le vrai zero), on aurait eu une seule
façon de représenter un nombre et je pense que ca n'aurait pas changé
grand chose aux routines de printf/scanf (voir ca les aurait simplifiées).
Il n'y a pas de raison de grouper le 1er digit en 4 ou 1 bit.. de toute
façon la base de l'exponentielle est 2 (p=pow(2,.)), donc ca signifie
qu'on travaille avec un alignement de 1bit fondamentalement. Je dis pas,
si on avait dit que p signifiait 16, alors là oui ca aurait eu du sens
de dire que le 1er digit est dans 0..9a..f.. mais avec un alignement au
bit près, on aurait dit que c'était toujours le digit de poids fort,
j'aurais trouvé ca super logique. Mais bon on a peut être voulu faire
plaisir à ceux qui voulaient que M_PI commence par un 3 aussi quand il
est représenté en flottant base 16.
sam (bits à zéro, tête à toto!)
Antoine Leca a écrit :Samuel DEVULDER a écrit :Vincent Lefevre a écrit :On dirait que "%a" affiche tous les quartets (tranche de 4bits) du
double sauf ceux de poids faibles ne contenant que du zero. C'est
l'équivalent d'une représentation décimale où l'on affiche pas les
zero terminaux.
Pas exactement, au sens où le premier quartet peut avoir 4 valeurs
possibles, suivant que l'on considère qu'il y a 0, 1, 2 ou 3 zéros
en tête (les implémentations diffèrent). En effet, l'exposant est
heu? je ne pige pas. Tu veux dire qu'on peut avoir 0x100p0 pour
représenter 256.0 ?
Non. Ce que veut dire Vincent, c'est que pour écrire 256.0, tu peut (au
choix de l'implémentation) récupérer n'importe lequel de
0x1p+8
0x2p+7
0x4p+6
0x8p+5
(fait de tête, sans machine)C'est quoi ces zéros de têtes..
En fait les zeros de têtes sont les *bits* à zero qu'on décide de placer
dans la partie avant le point.
Punaise. Zero et bit à zero c'est pas pareil! Sans déconner ca aide pas
à comprendre.. moi je parlais des zéros hexa en fin de nombre et d'un
autre coté on parle de bit à zero au début, tout cela en parlant de zéro
comme si il n'y avait qu'un seul zéro. Pas facile!
Ok c'est plus clair à présent, sauf que je ne vois pas pourquoi on a
laissé un choix arbitraire pour ce 1er digit. On aurait pris le 1
universel (c'est le même dans toutes les bases), et toujours là dans le
cadre flottant IEEE (sauf pour le vrai zero), on aurait eu une seule
façon de représenter un nombre et je pense que ca n'aurait pas changé
grand chose aux routines de printf/scanf (voir ca les aurait simplifiées).
Il n'y a pas de raison de grouper le 1er digit en 4 ou 1 bit.. de toute
façon la base de l'exponentielle est 2 (p=pow(2,.)), donc ca signifie
qu'on travaille avec un alignement de 1bit fondamentalement. Je dis pas,
si on avait dit que p signifiait 16, alors là oui ca aurait eu du sens
de dire que le 1er digit est dans 0..9a..f.. mais avec un alignement au
bit près, on aurait dit que c'était toujours le digit de poids fort,
j'aurais trouvé ca super logique. Mais bon on a peut être voulu faire
plaisir à ceux qui voulaient que M_PI commence par un 3 aussi quand il
est représenté en flottant base 16.
sam (bits à zéro, tête à toto!)
> Relis ce que je dis: je parle de long sur 64 bits (cas le plus courant
> sur machines 64 bits).
Heu.. oui mais "long int" c'est 32bits chez moi. Pour du 64bit j'écris
"long long int". J'ai loupé un truc? Je n'ai jamais parlé de machine
64bits. Je vois pas d'où elle sort cette babasse là.
Finalement Misra-C a raison avec le bannissement du type "int" dans le
code. Ca n'est pas suffisant quand le nombre de bit est important.
> Relis ce que je dis: je parle de long sur 64 bits (cas le plus courant
> sur machines 64 bits).
Heu.. oui mais "long int" c'est 32bits chez moi. Pour du 64bit j'écris
"long long int". J'ai loupé un truc? Je n'ai jamais parlé de machine
64bits. Je vois pas d'où elle sort cette babasse là.
Finalement Misra-C a raison avec le bannissement du type "int" dans le
code. Ca n'est pas suffisant quand le nombre de bit est important.
> Relis ce que je dis: je parle de long sur 64 bits (cas le plus courant
> sur machines 64 bits).
Heu.. oui mais "long int" c'est 32bits chez moi. Pour du 64bit j'écris
"long long int". J'ai loupé un truc? Je n'ai jamais parlé de machine
64bits. Je vois pas d'où elle sort cette babasse là.
Finalement Misra-C a raison avec le bannissement du type "int" dans le
code. Ca n'est pas suffisant quand le nombre de bit est important.
