int main(void) {
float x;
x = 1.7;
return ((x + 0.1) == 1.8) ? 1 : 0;
}
j'obtiens :
$ gcc -Wall -o essai essai.c; ./essai; echo $?
0
Pourtant, le programme
#include <stdio.h>
int main(void) {
float x;
x = 1.7;
printf("%f et %f\n", 1.7 + 0.1, x + 0.1);
}
affiche :
1.800000 et 1.800000
Apparremment, 1.7+0.1 et x+0.1 sont égaux ; j'imagine qu'il s'agit d'un
problème de représentation des flottants en machine mais j'aimerais bien
avoir une confirmation ou une infirmation (et une explication, si possible).
Non, je faisais référence au msg d'origine en réponse à Antoine :
----8<-----------------------
Antoine Leca a écrit :
Il reste Microsoft qui eux sont restés sur long2 bits, tout en expliquant qu'il ne faut pas utiliser les types de base (ni printf).
Avec un peu plus de contexte, on verrait que je parlais des machines 64 bits.
Antoine
Antoine Leca
Vincent Belaïche écrivit :
| format | %e, %g, %f | %a | en mémoire | |------------------------------------+------------+----+------------| | base de numération de l'exposant | 10 | 10 | 2 | | base de logarithme de l'exposant | 10 | 2 | 2 | | base de numération du significande | 10 | 16 | 2 |
Oui sauf pour la dernière colonne. C'est complètement orthogonal, et rien ne te permet de faire des affirmations dessus en règle générale (et il y a des existants avec 2, d'autres avec 10 et d'autres avec 16; plus 20, 60 et 360 en dehors de l'informatique).
Antoine
Vincent Belaïche écrivit :
| format | %e, %g, %f | %a | en mémoire |
|------------------------------------+------------+----+------------|
| base de numération de l'exposant | 10 | 10 | 2 |
| base de logarithme de l'exposant | 10 | 2 | 2 |
| base de numération du significande | 10 | 16 | 2 |
Oui sauf pour la dernière colonne. C'est complètement orthogonal, et
rien ne te permet de faire des affirmations dessus en règle générale
(et il y a des existants avec 2, d'autres avec 10 et d'autres avec 16;
plus 20, 60 et 360 en dehors de l'informatique).
| format | %e, %g, %f | %a | en mémoire | |------------------------------------+------------+----+------------| | base de numération de l'exposant | 10 | 10 | 2 | | base de logarithme de l'exposant | 10 | 2 | 2 | | base de numération du significande | 10 | 16 | 2 |
Oui sauf pour la dernière colonne. C'est complètement orthogonal, et rien ne te permet de faire des affirmations dessus en règle générale (et il y a des existants avec 2, d'autres avec 10 et d'autres avec 16; plus 20, 60 et 360 en dehors de l'informatique).
Antoine
Antoine Leca
Marc Espie écrivit :
De toutes facons, la norme C est en grande partie silencieuse concernant les flottants. De memoire, elle mentionne surtout qu'une implementation decente devrait dire si elle utilise aussi IEEE754 ou pas.
Tu es trop réducteur ! La norme n'est pas d'une précision absolue, et le niveau de spécification inférieur à ce que l'on peut trouver ailleurs (je pense à Ada), même si C99 a beaucoup progressé à ce niveau. Mais en dehors de signaler clairement la conformité (supposée) à IEEE 754 avec tout ce que cela implique, il y a pas mal d'autres contraintes et recommandations de ci, de là, sur les propriétés des flottants.
Ce qui implique donc que...
Ca n'empeche pas d'etre precis et d'essayer de faire maximalement portable, mais c'est vraiment un domaine ou il convient de faire tres tres attention a ce qu'on raconte.
Tout-à-fait d'accord !
Antoine
Marc Espie écrivit :
De toutes facons, la norme C est en grande partie silencieuse concernant
les flottants. De memoire, elle mentionne surtout qu'une implementation
decente devrait dire si elle utilise aussi IEEE754 ou pas.
Tu es trop réducteur !
La norme n'est pas d'une précision absolue, et le niveau de
spécification inférieur à ce que l'on peut trouver ailleurs (je pense à
Ada), même si C99 a beaucoup progressé à ce niveau. Mais en dehors de
signaler clairement la conformité (supposée) à IEEE 754 avec tout ce que
cela implique, il y a pas mal d'autres contraintes et recommandations de
ci, de là, sur les propriétés des flottants.
Ce qui implique donc que...
Ca n'empeche pas d'etre precis et d'essayer de faire maximalement portable,
mais c'est vraiment un domaine ou il convient de faire tres tres attention
a ce qu'on raconte.
De toutes facons, la norme C est en grande partie silencieuse concernant les flottants. De memoire, elle mentionne surtout qu'une implementation decente devrait dire si elle utilise aussi IEEE754 ou pas.
Tu es trop réducteur ! La norme n'est pas d'une précision absolue, et le niveau de spécification inférieur à ce que l'on peut trouver ailleurs (je pense à Ada), même si C99 a beaucoup progressé à ce niveau. Mais en dehors de signaler clairement la conformité (supposée) à IEEE 754 avec tout ce que cela implique, il y a pas mal d'autres contraintes et recommandations de ci, de là, sur les propriétés des flottants.
Ce qui implique donc que...
Ca n'empeche pas d'etre precis et d'essayer de faire maximalement portable, mais c'est vraiment un domaine ou il convient de faire tres tres attention a ce qu'on raconte.
Tout-à-fait d'accord !
Antoine
Vincent Lefevre
Dans l'article <hphoa4$1ldm$, Marc Espie écrit:
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef sauf des cas parfaitement definis (en gros, typedef pour les types de pointeur de fonction, parce que sinon c'est vraiment imbitable).
Et pour les enum, et pour les structures?
Je trouve les typedef utiles pour les bibliothèques, afin de cacher l'implémentation interne à l'utilisateur, et afin de pouvoir changer (on évite tout de même) sans casser l'API.
Par exemple, si je suis sous Unix, je peux tres bien ecrire: pid_t fd = open("/etc/passwd", O_RDONLY); et mon compilo ne bronchera pas...
C'est une limite des typedef, qui ne définissent pas des nouveaux types. Ce n'est pas une raison pour ne pas les utiliser.
Dans l'article <hphoa4$1ldm$5@saria.nerim.net>,
Marc Espie <espie@lain.home> écrit:
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef
sauf des cas parfaitement definis (en gros, typedef pour les types de
pointeur de fonction, parce que sinon c'est vraiment imbitable).
Et pour les enum, et pour les structures?
Je trouve les typedef utiles pour les bibliothèques, afin de cacher
l'implémentation interne à l'utilisateur, et afin de pouvoir changer
(on évite tout de même) sans casser l'API.
Par exemple, si je suis sous Unix, je peux tres bien ecrire:
pid_t fd = open("/etc/passwd", O_RDONLY);
et mon compilo ne bronchera pas...
C'est une limite des typedef, qui ne définissent pas des nouveaux
types. Ce n'est pas une raison pour ne pas les utiliser.
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef sauf des cas parfaitement definis (en gros, typedef pour les types de pointeur de fonction, parce que sinon c'est vraiment imbitable).
Et pour les enum, et pour les structures?
Je trouve les typedef utiles pour les bibliothèques, afin de cacher l'implémentation interne à l'utilisateur, et afin de pouvoir changer (on évite tout de même) sans casser l'API.
Par exemple, si je suis sous Unix, je peux tres bien ecrire: pid_t fd = open("/etc/passwd", O_RDONLY); et mon compilo ne bronchera pas...
C'est une limite des typedef, qui ne définissent pas des nouveaux types. Ce n'est pas une raison pour ne pas les utiliser.
Vincent Lefevre écrivit : > Bref, cette notion de type implicite était foireuse dès le départ.
Non.
C est devenu de plus en plus compliqué, et à un moment cette nouvelle complexité nécessite que des choses qui furent simples et limpides deviennent des cas particuliers de situations plus complexes ; pour assurer la transition, le mécanisme des choses implicites est une aide précieuse dans un premier temps, mais ensuite il faut s'en passer.
Ils auraient dû alors rendre le int implicite obsolète (mais toujours supporté par les implémentations pour compatibilité) dès que ça devenait complexe, par exemple en C89.
Dans l'article <hphj3o$96e$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Vincent Lefevre écrivit :
> Bref, cette notion de type implicite était foireuse dès le départ.
Non.
C est devenu de plus en plus compliqué, et à un moment cette nouvelle
complexité nécessite que des choses qui furent simples et limpides
deviennent des cas particuliers de situations plus complexes ; pour
assurer la transition, le mécanisme des choses implicites est une aide
précieuse dans un premier temps, mais ensuite il faut s'en passer.
Ils auraient dû alors rendre le int implicite obsolète (mais
toujours supporté par les implémentations pour compatibilité)
dès que ça devenait complexe, par exemple en C89.
Vincent Lefevre écrivit : > Bref, cette notion de type implicite était foireuse dès le départ.
Non.
C est devenu de plus en plus compliqué, et à un moment cette nouvelle complexité nécessite que des choses qui furent simples et limpides deviennent des cas particuliers de situations plus complexes ; pour assurer la transition, le mécanisme des choses implicites est une aide précieuse dans un premier temps, mais ensuite il faut s'en passer.
Ils auraient dû alors rendre le int implicite obsolète (mais toujours supporté par les implémentations pour compatibilité) dès que ça devenait complexe, par exemple en C89.
Surprise! les normes ont des défauts. Les plus graves sont corrigés (le troisième jeu de révision de C99 date de 2007, je doute qu'il y en ai un autre avant la publication de C1X), quand on s'en rend compte, que ce n'est pas trop invasif, et qu'on se met d'accord sur la correction. Mon impression est qu'ici le problème est tellement peu grave que la correction en serait laissée à l'éditeur (comme les fautes d'orthographe et les incohérences de typographie ne créant pas d'ambiguité) et jamais publiée dans un TC. Ça ne m'étonnerait pas du tout que Vincent ait connaissance de problèmes techniques plus graves concernant les nombres à virgule flottante.
Dans l'article <87vdc34qg5.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
Surprise! les normes ont des défauts. Les plus graves sont corrigés (le
troisième jeu de révision de C99 date de 2007, je doute qu'il y en ai un
autre avant la publication de C1X), quand on s'en rend compte, que ce n'est
pas trop invasif, et qu'on se met d'accord sur la correction. Mon
impression est qu'ici le problème est tellement peu grave que la correction
en serait laissée à l'éditeur (comme les fautes d'orthographe et les
incohérences de typographie ne créant pas d'ambiguité) et jamais publiée
dans un TC. Ça ne m'étonnerait pas du tout que Vincent ait connaissance de
problèmes techniques plus graves concernant les nombres à virgule
flottante.
Surprise! les normes ont des défauts. Les plus graves sont corrigés (le troisième jeu de révision de C99 date de 2007, je doute qu'il y en ai un autre avant la publication de C1X), quand on s'en rend compte, que ce n'est pas trop invasif, et qu'on se met d'accord sur la correction. Mon impression est qu'ici le problème est tellement peu grave que la correction en serait laissée à l'éditeur (comme les fautes d'orthographe et les incohérences de typographie ne créant pas d'ambiguité) et jamais publiée dans un TC. Ça ne m'étonnerait pas du tout que Vincent ait connaissance de problèmes techniques plus graves concernant les nombres à virgule flottante.
assurer la transition, le mécanisme des choses implicites est une aide précieuse dans un premier temps, mais ensuite il faut s'en passer.
Ils auraient dû alors rendre le int implicite obsolète
Certes. Mais c'était il y a bien longtemps (1987).
Antoine
Vincent Belaïche
OK, la représentation textuelle est complètement orthogonale de la représentation en mémoire, et dépend de la machine.
J'avais ajouté la dernière colonne parce que la discussion était partie sur ce que veut dire "binaire" ou "décimal" lorsque on parle de nombre binaire ou de nombre "décimal". Je maintiens que, en français, lorsque on applique cette épithète au mot nombre, on fait référence à ses propriétés mathématiques, qui en dernier ressort dépendent de la façon dont il est mémorisé dans la machine.
En ce qui concerne la dernière colonne je considérais donc en effet une machine particulière (c'est ce qu'on trouve en général dans les PC).
Toujours est-il que je maintiens aussi que dans "binary exponent part", "binary" est en rapport avec la base de logarithme utilisée pour la repésentation textuelle avec %a, et non avec le fait que l'exposant est en général un nombre binaire, c'est à dire avec une base de numération 2 en mémoire (par ex. sur une machine où la dernière colonne est vraie).
Vincent.
Antoine Leca a écrit :
Vincent Belaïche écrivit :
| format | %e, %g, %f | %a | en mémoire | |------------------------------------+------------+----+------------| | base de numération de l'exposant | 10 | 10 | 2 | | base de logarithme de l'exposant | 10 | 2 | 2 | | base de numération du significande | 10 | 16 | 2 |
Oui sauf pour la dernière colonne. C'est complètement orthogonal, et rien ne te permet de faire des affirmations dessus en règle générale (et il y a des existants avec 2, d'autres avec 10 et d'autres avec 16; plus 20, 60 et 360 en dehors de l'informatique).
Antoine
OK, la représentation textuelle est complètement orthogonale de la
représentation en mémoire, et dépend de la machine.
J'avais ajouté la dernière colonne parce que la discussion était partie
sur ce que veut dire "binaire" ou "décimal" lorsque on parle de nombre
binaire ou de nombre "décimal". Je maintiens que, en français, lorsque
on applique cette épithète au mot nombre, on fait référence à ses
propriétés mathématiques, qui en dernier ressort dépendent de la façon
dont il est mémorisé dans la machine.
En ce qui concerne la dernière colonne je considérais donc en effet une
machine particulière (c'est ce qu'on trouve en général dans les PC).
Toujours est-il que je maintiens aussi que dans "binary exponent part",
"binary" est en rapport avec la base de logarithme utilisée pour la
repésentation textuelle avec %a, et non avec le fait que l'exposant est
en général un nombre binaire, c'est à dire avec une base de numération 2
en mémoire (par ex. sur une machine où la dernière colonne est vraie).
Vincent.
Antoine Leca a écrit :
Vincent Belaïche écrivit :
| format | %e, %g, %f | %a | en mémoire |
|------------------------------------+------------+----+------------|
| base de numération de l'exposant | 10 | 10 | 2 |
| base de logarithme de l'exposant | 10 | 2 | 2 |
| base de numération du significande | 10 | 16 | 2 |
Oui sauf pour la dernière colonne. C'est complètement orthogonal, et
rien ne te permet de faire des affirmations dessus en règle générale
(et il y a des existants avec 2, d'autres avec 10 et d'autres avec 16;
plus 20, 60 et 360 en dehors de l'informatique).
OK, la représentation textuelle est complètement orthogonale de la représentation en mémoire, et dépend de la machine.
J'avais ajouté la dernière colonne parce que la discussion était partie sur ce que veut dire "binaire" ou "décimal" lorsque on parle de nombre binaire ou de nombre "décimal". Je maintiens que, en français, lorsque on applique cette épithète au mot nombre, on fait référence à ses propriétés mathématiques, qui en dernier ressort dépendent de la façon dont il est mémorisé dans la machine.
En ce qui concerne la dernière colonne je considérais donc en effet une machine particulière (c'est ce qu'on trouve en général dans les PC).
Toujours est-il que je maintiens aussi que dans "binary exponent part", "binary" est en rapport avec la base de logarithme utilisée pour la repésentation textuelle avec %a, et non avec le fait que l'exposant est en général un nombre binaire, c'est à dire avec une base de numération 2 en mémoire (par ex. sur une machine où la dernière colonne est vraie).
Vincent.
Antoine Leca a écrit :
Vincent Belaïche écrivit :
| format | %e, %g, %f | %a | en mémoire | |------------------------------------+------------+----+------------| | base de numération de l'exposant | 10 | 10 | 2 | | base de logarithme de l'exposant | 10 | 2 | 2 | | base de numération du significande | 10 | 16 | 2 |
Oui sauf pour la dernière colonne. C'est complètement orthogonal, et rien ne te permet de faire des affirmations dessus en règle générale (et il y a des existants avec 2, d'autres avec 10 et d'autres avec 16; plus 20, 60 et 360 en dehors de l'informatique).
Antoine
Samuel DEVULDER
Vincent Belaïche a écrit :
OK, la représentation textuelle est complètement orthogonale de la représentation en mémoire, et dépend de la machine.
J'avais ajouté la dernière colonne parce que la discussion était partie sur ce que veut dire "binaire" ou "décimal" lorsque on parle de nombre binaire ou de nombre "décimal". Je maintiens que, en français, lorsque on applique cette épithète au mot nombre, on fait référence à ses propriétés mathématiques, qui en dernier ressort dépendent de la façon dont il est mémorisé dans la machine.
Je ne suis pas d'accord. Décimal ou binaire n'est absolument pas une propriété intrinsèque d'un nombre. Un nombre est un truc qui existe indépendamment de la façon de l'écrire. Est-ce que sqrt(2) est binaire ou décimal? Ni l'un ni l'autre, par contre on peut le *représenter* avec des chiffres binaires ou décimaux.
En fait binaire ou décimal ne s'applique qu'aux chiffres et pas aux nombres. Ce sont des symboles et pas des valeurs. Le français nous trompe car on parle facilement de chiffres quand on veut parler de nombres. C'est d'ailleurs assez amusant d'entendre "je ne vous donnerais qu'un seul chiffre: 15 pourcent des gens blabla".. Perdu! Le nombre 15 c'est deux chiffres et pas un seul.
Pour en revenir aux binaire/décimaux: Les chiffres sont l'ensemble des symboles utilisés pour représenter ce nombre dans un système de numération. Le décimal correspond à un alphabet de dix symboles, le binaire à deux symboles seulement.
A noter pour la culture générale que certains nombres ne seront jamais pratiquement représentable sous une forme décimale ou binaire parce soit ils sont trop grands et qu'il faut recourrir à une autre facon de les représenter (cf les exponentielles itérées de Knuth), soit ils ne sont même pas calculables (nombre Oméga de Chaitin, qui pourtant possède une définition qui pourrait s'apparenter à une notation binaire). L'interêt pratique de ces nombres "abstraits" reste cependant à être démontrée.
En ce qui concerne la dernière colonne je considérais donc en effet une machine particulière (c'est ce qu'on trouve en général dans les PC).
Toujours est-il que je maintiens aussi que dans "binary exponent part", "binary" est en rapport avec la base de logarithme utilisée pour la repésentation textuelle
Oui mais dans ce cas cela ne précise pas la base utilisée pour représenter cet exposant. La partie que l'on trouve p279, pourtant fort décriée par les spécialistes ici, est de ce point de vue là infiniment plus claire et utile:
"...as manymore digits as necessary to represent the decimal exponent of 2"
qu'on peut traduire par "et autant de *chiffres* que nécessaire pour représenter l'exposant décimal de 2". Tout y est dit avec précision: la puissance: 2, la base des chiffres utilisés: dix, leur nombre: "autant qu'il faut".
Du reste "binary-exponent-part" ne désigne pas un nombre, mais plutôt une zone du format, une partie, une tranche. C'est celle qui va de "p" jusqu'au dernier chiffre décimal. C'est pour cela qu'on trouve cette expression toujours en relation avec la grammaire BNF du C (6.4.4.2), toujours en relation avec la façon de reconnaitre un float hexa (analyse lexicale/syntaxique réalisable par une machine à états finis), mais pas sur façon de l'interpréter (qui nécessite un peu plus de puissance de calcul qu'une simple FSM).
avec %a, et non avec le fait que l'exposant est
en général un nombre binaire, c'est à dire avec une base de numération 2 en mémoire (par ex. sur une machine où la dernière colonne est vraie).
Non l'interprétation d'une float hexa ne dépend pas de la façon dont on le construit en mémoire: on peut lire un float hexa base 2 en entrée et stocker en mémoire une représentation BCD, ou decimal32.
sam.
Vincent Belaïche a écrit :
OK, la représentation textuelle est complètement orthogonale de la
représentation en mémoire, et dépend de la machine.
J'avais ajouté la dernière colonne parce que la discussion était partie
sur ce que veut dire "binaire" ou "décimal" lorsque on parle de nombre
binaire ou de nombre "décimal". Je maintiens que, en français, lorsque
on applique cette épithète au mot nombre, on fait référence à ses
propriétés mathématiques, qui en dernier ressort dépendent de la façon
dont il est mémorisé dans la machine.
Je ne suis pas d'accord. Décimal ou binaire n'est absolument pas une
propriété intrinsèque d'un nombre. Un nombre est un truc qui existe
indépendamment de la façon de l'écrire. Est-ce que sqrt(2) est binaire
ou décimal? Ni l'un ni l'autre, par contre on peut le *représenter* avec
des chiffres binaires ou décimaux.
En fait binaire ou décimal ne s'applique qu'aux chiffres et pas aux
nombres. Ce sont des symboles et pas des valeurs. Le français nous
trompe car on parle facilement de chiffres quand on veut parler de
nombres. C'est d'ailleurs assez amusant d'entendre "je ne vous donnerais
qu'un seul chiffre: 15 pourcent des gens blabla".. Perdu! Le nombre 15
c'est deux chiffres et pas un seul.
Pour en revenir aux binaire/décimaux: Les chiffres sont l'ensemble des
symboles utilisés pour représenter ce nombre dans un système de
numération. Le décimal correspond à un alphabet de dix symboles, le
binaire à deux symboles seulement.
A noter pour la culture générale que certains nombres ne seront jamais
pratiquement représentable sous une forme décimale ou binaire parce soit
ils sont trop grands et qu'il faut recourrir à une autre facon de les
représenter (cf les exponentielles itérées de Knuth), soit ils ne sont
même pas calculables (nombre Oméga de Chaitin, qui pourtant possède une
définition qui pourrait s'apparenter à une notation binaire). L'interêt
pratique de ces nombres "abstraits" reste cependant à être démontrée.
En ce qui concerne la dernière colonne je considérais donc en effet une
machine particulière (c'est ce qu'on trouve en général dans les PC).
Toujours est-il que je maintiens aussi que dans "binary exponent part",
"binary" est en rapport avec la base de logarithme utilisée pour la
repésentation textuelle
Oui mais dans ce cas cela ne précise pas la base utilisée pour
représenter cet exposant. La partie que l'on trouve p279, pourtant fort
décriée par les spécialistes ici, est de ce point de vue là infiniment
plus claire et utile:
"...as manymore digits as necessary to represent the
decimal exponent of 2"
qu'on peut traduire par "et autant de *chiffres* que nécessaire pour
représenter l'exposant décimal de 2". Tout y est dit avec précision: la
puissance: 2, la base des chiffres utilisés: dix, leur nombre: "autant
qu'il faut".
Du reste "binary-exponent-part" ne désigne pas un nombre, mais plutôt
une zone du format, une partie, une tranche. C'est celle qui va de "p"
jusqu'au dernier chiffre décimal. C'est pour cela qu'on trouve cette
expression toujours en relation avec la grammaire BNF du C (6.4.4.2),
toujours en relation avec la façon de reconnaitre un float hexa (analyse
lexicale/syntaxique réalisable par une machine à états finis), mais pas
sur façon de l'interpréter (qui nécessite un peu plus de puissance de
calcul qu'une simple FSM).
avec %a, et non avec le fait que l'exposant est
en général un nombre binaire, c'est à dire avec une base de numération 2
en mémoire (par ex. sur une machine où la dernière colonne est vraie).
Non l'interprétation d'une float hexa ne dépend pas de la façon dont on
le construit en mémoire: on peut lire un float hexa base 2 en entrée et
stocker en mémoire une représentation BCD, ou decimal32.
OK, la représentation textuelle est complètement orthogonale de la représentation en mémoire, et dépend de la machine.
J'avais ajouté la dernière colonne parce que la discussion était partie sur ce que veut dire "binaire" ou "décimal" lorsque on parle de nombre binaire ou de nombre "décimal". Je maintiens que, en français, lorsque on applique cette épithète au mot nombre, on fait référence à ses propriétés mathématiques, qui en dernier ressort dépendent de la façon dont il est mémorisé dans la machine.
Je ne suis pas d'accord. Décimal ou binaire n'est absolument pas une propriété intrinsèque d'un nombre. Un nombre est un truc qui existe indépendamment de la façon de l'écrire. Est-ce que sqrt(2) est binaire ou décimal? Ni l'un ni l'autre, par contre on peut le *représenter* avec des chiffres binaires ou décimaux.
En fait binaire ou décimal ne s'applique qu'aux chiffres et pas aux nombres. Ce sont des symboles et pas des valeurs. Le français nous trompe car on parle facilement de chiffres quand on veut parler de nombres. C'est d'ailleurs assez amusant d'entendre "je ne vous donnerais qu'un seul chiffre: 15 pourcent des gens blabla".. Perdu! Le nombre 15 c'est deux chiffres et pas un seul.
Pour en revenir aux binaire/décimaux: Les chiffres sont l'ensemble des symboles utilisés pour représenter ce nombre dans un système de numération. Le décimal correspond à un alphabet de dix symboles, le binaire à deux symboles seulement.
A noter pour la culture générale que certains nombres ne seront jamais pratiquement représentable sous une forme décimale ou binaire parce soit ils sont trop grands et qu'il faut recourrir à une autre facon de les représenter (cf les exponentielles itérées de Knuth), soit ils ne sont même pas calculables (nombre Oméga de Chaitin, qui pourtant possède une définition qui pourrait s'apparenter à une notation binaire). L'interêt pratique de ces nombres "abstraits" reste cependant à être démontrée.
En ce qui concerne la dernière colonne je considérais donc en effet une machine particulière (c'est ce qu'on trouve en général dans les PC).
Toujours est-il que je maintiens aussi que dans "binary exponent part", "binary" est en rapport avec la base de logarithme utilisée pour la repésentation textuelle
Oui mais dans ce cas cela ne précise pas la base utilisée pour représenter cet exposant. La partie que l'on trouve p279, pourtant fort décriée par les spécialistes ici, est de ce point de vue là infiniment plus claire et utile:
"...as manymore digits as necessary to represent the decimal exponent of 2"
qu'on peut traduire par "et autant de *chiffres* que nécessaire pour représenter l'exposant décimal de 2". Tout y est dit avec précision: la puissance: 2, la base des chiffres utilisés: dix, leur nombre: "autant qu'il faut".
Du reste "binary-exponent-part" ne désigne pas un nombre, mais plutôt une zone du format, une partie, une tranche. C'est celle qui va de "p" jusqu'au dernier chiffre décimal. C'est pour cela qu'on trouve cette expression toujours en relation avec la grammaire BNF du C (6.4.4.2), toujours en relation avec la façon de reconnaitre un float hexa (analyse lexicale/syntaxique réalisable par une machine à états finis), mais pas sur façon de l'interpréter (qui nécessite un peu plus de puissance de calcul qu'une simple FSM).
avec %a, et non avec le fait que l'exposant est
en général un nombre binaire, c'est à dire avec une base de numération 2 en mémoire (par ex. sur une machine où la dernière colonne est vraie).
Non l'interprétation d'une float hexa ne dépend pas de la façon dont on le construit en mémoire: on peut lire un float hexa base 2 en entrée et stocker en mémoire une représentation BCD, ou decimal32.
sam.
espie
In article <20100407160607$, Vincent Lefevre wrote:
Dans l'article <hphoa4$1ldm$, Marc Espie écrit:
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef sauf des cas parfaitement definis (en gros, typedef pour les types de pointeur de fonction, parce que sinon c'est vraiment imbitable).
Et pour les enum, et pour les structures?
Ca ne sert a rien pour les enum, ni pour les structures, ou ca cache le fait que c'est une structure, ce qui est tres bof.
Je trouve les typedef utiles pour les bibliothèques, afin de cacher l'implémentation interne à l'utilisateur, et afin de pouvoir changer (on évite tout de même) sans casser l'API.
... et tu fais comment pour etre sur que tes noms ne vont pas empieter sur ceux des voisins dans les fichiers d'entete ? pour avoir eu deja affaire a ce genre de casse-tete, et plus d'une fois, je dis non.
Par exemple, si je suis sous Unix, je peux tres bien ecrire: pid_t fd = open("/etc/passwd", O_RDONLY); et mon compilo ne bronchera pas...
C'est une limite des typedef, qui ne définissent pas des nouveaux types. Ce n'est pas une raison pour ne pas les utiliser.
Si, c'est une raison. Ils n'apportent rien en terme de surete du code, et donnent juste l'impression que ce qu'on fait est plus propre. Si je veux programmer en autre chose que C, je fais autre chose que le C. Je ne fais pas semblant avec les moyens merdiques que propose le C pour "definir" de nouveaux types...
In article <20100407160607$5b2a@prunille.vinc17.org>,
Vincent Lefevre <vincent-news@vinc17.net> wrote:
Dans l'article <hphoa4$1ldm$5@saria.nerim.net>,
Marc Espie <espie@lain.home> écrit:
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef
sauf des cas parfaitement definis (en gros, typedef pour les types de
pointeur de fonction, parce que sinon c'est vraiment imbitable).
Et pour les enum, et pour les structures?
Ca ne sert a rien pour les enum, ni pour les structures, ou ca cache le
fait que c'est une structure, ce qui est tres bof.
Je trouve les typedef utiles pour les bibliothèques, afin de cacher
l'implémentation interne à l'utilisateur, et afin de pouvoir changer
(on évite tout de même) sans casser l'API.
... et tu fais comment pour etre sur que tes noms ne vont pas empieter
sur ceux des voisins dans les fichiers d'entete ? pour avoir eu deja affaire
a ce genre de casse-tete, et plus d'une fois, je dis non.
Par exemple, si je suis sous Unix, je peux tres bien ecrire:
pid_t fd = open("/etc/passwd", O_RDONLY);
et mon compilo ne bronchera pas...
C'est une limite des typedef, qui ne définissent pas des nouveaux
types. Ce n'est pas une raison pour ne pas les utiliser.
Si, c'est une raison. Ils n'apportent rien en terme de surete du code, et
donnent juste l'impression que ce qu'on fait est plus propre. Si je veux
programmer en autre chose que C, je fais autre chose que le C. Je ne fais
pas semblant avec les moyens merdiques que propose le C pour "definir" de
nouveaux types...
In article <20100407160607$, Vincent Lefevre wrote:
Dans l'article <hphoa4$1ldm$, Marc Espie écrit:
Quand j'enseigne le C, je deconseille totalement l'utilisation de typedef sauf des cas parfaitement definis (en gros, typedef pour les types de pointeur de fonction, parce que sinon c'est vraiment imbitable).
Et pour les enum, et pour les structures?
Ca ne sert a rien pour les enum, ni pour les structures, ou ca cache le fait que c'est une structure, ce qui est tres bof.
Je trouve les typedef utiles pour les bibliothèques, afin de cacher l'implémentation interne à l'utilisateur, et afin de pouvoir changer (on évite tout de même) sans casser l'API.
... et tu fais comment pour etre sur que tes noms ne vont pas empieter sur ceux des voisins dans les fichiers d'entete ? pour avoir eu deja affaire a ce genre de casse-tete, et plus d'une fois, je dis non.
Par exemple, si je suis sous Unix, je peux tres bien ecrire: pid_t fd = open("/etc/passwd", O_RDONLY); et mon compilo ne bronchera pas...
C'est une limite des typedef, qui ne définissent pas des nouveaux types. Ce n'est pas une raison pour ne pas les utiliser.
Si, c'est une raison. Ils n'apportent rien en terme de surete du code, et donnent juste l'impression que ce qu'on fait est plus propre. Si je veux programmer en autre chose que C, je fais autre chose que le C. Je ne fais pas semblant avec les moyens merdiques que propose le C pour "definir" de nouveaux types...
