Il est bien connu que la norme IEEE 754 n'est pas forcément supportée
en C, mais si __STDC_IEC_559__ est défini, on doit s'attendre à un
certain nombre de choses:
Annex F
(normative)
IEC 60559 floating-point arithmetic
[...]
60559 operation, IEC 60559 format, etc. An implementation
that defines __STDC_IEC_559__ shall conform to the |
specifications in this annex. Where a binding between the C
language and IEC 60559 is indicated, the IEC 60559-specified
behavior is adopted by reference, unless stated otherwise.
F.2 Types
[#1] The C floating types match the IEC 60559 formats as
follows:
-- The float type matches the IEC 60559 single format.
-- The double type matches the IEC 60559 double format.
[...]
F.3 Operators and functions
[#1] C operators and functions provide IEC 60559 required
and recommended facilities as listed below.
-- The +, -, *, and / operators provide the IEC 60559 add,
subtract, multiply, and divide operations.
[...]
Maintenant, qu'en est-il avec gcc? Considérons le programme suivant:
D'accord pour le double arrondi (et oui, cela peut amener une différence), mais là j'ai pas vu en quoi ton exemple invoquait une quelconque différence. J'ai loupé quelque chose, ou c'est toi qui a loupé quelque chose avec ton 65536.0 qu'il faudrait remplacer par un 1024.0, et là oui il y a un pépin si Linux te donne 9007199254740994 au lieu du « correct » 9007199254740996 (si on te suit au sujet de l'obligation de faire les calculs intermédiaires en 53 bits.)
9007199254740994 est un entier de 54 bits congru à 2 module 4, donc a une mantisse impaire. Le résultat exact est un peu en-dessous de 9007199254740995, milieu de deux nombres représentables consécutifs (9007199254740994 et 9007199254740996). Donc le résultat correct est 9007199254740994.
D'autre part peux-tu m'expliquer
F.7.3 Execution
[#1] At program startup the floating-point environment is initialized as prescribed by IEC 60559: [couic] -- The dynamic rounding precision mode (if supported) is set so that results are not shortened.
C'est à dire que si on fait double + double, on ne doit pas se retrouver avec de la simple précision.
Est-ce que par hasard le mode de précision dynamique a un rapport, même lointain, avec le contrôle de précision du x87?
Et à propos, que vaut sizeof(double_t) ? 8 (=> calculs en 53 bits), ou 10/12/16 (=> calculs en 64 bits) ?
D'abord, tout dépend de la taille d'un char. :) Tout dépend aussi de FLT_EVAL_METHOD.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <bh87o6$del$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
D'accord pour le double arrondi (et oui, cela peut amener une
différence), mais là j'ai pas vu en quoi ton exemple invoquait une
quelconque différence.
J'ai loupé quelque chose, ou c'est toi qui a loupé quelque chose avec
ton 65536.0 qu'il faudrait remplacer par un 1024.0, et là oui il y a
un pépin si Linux te donne 9007199254740994 au lieu du
« correct » 9007199254740996 (si on te suit au sujet de l'obligation
de faire les calculs intermédiaires en 53 bits.)
9007199254740994 est un entier de 54 bits congru à 2 module 4, donc
a une mantisse impaire. Le résultat exact est un peu en-dessous de
9007199254740995, milieu de deux nombres représentables consécutifs
(9007199254740994 et 9007199254740996). Donc le résultat correct
est 9007199254740994.
D'autre part peux-tu m'expliquer
F.7.3 Execution
[#1] At program startup the floating-point environment is
initialized as prescribed by IEC 60559:
[couic]
-- The dynamic rounding precision mode (if supported) is
set so that results are not shortened.
C'est à dire que si on fait double + double, on ne doit pas se retrouver
avec de la simple précision.
Est-ce que par hasard le mode de précision dynamique a un rapport,
même lointain, avec le contrôle de précision du x87?
Et à propos, que vaut sizeof(double_t) ? 8 (=> calculs en 53 bits), ou
10/12/16 (=> calculs en 64 bits) ?
D'abord, tout dépend de la taille d'un char. :) Tout dépend aussi de
FLT_EVAL_METHOD.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
D'accord pour le double arrondi (et oui, cela peut amener une différence), mais là j'ai pas vu en quoi ton exemple invoquait une quelconque différence. J'ai loupé quelque chose, ou c'est toi qui a loupé quelque chose avec ton 65536.0 qu'il faudrait remplacer par un 1024.0, et là oui il y a un pépin si Linux te donne 9007199254740994 au lieu du « correct » 9007199254740996 (si on te suit au sujet de l'obligation de faire les calculs intermédiaires en 53 bits.)
9007199254740994 est un entier de 54 bits congru à 2 module 4, donc a une mantisse impaire. Le résultat exact est un peu en-dessous de 9007199254740995, milieu de deux nombres représentables consécutifs (9007199254740994 et 9007199254740996). Donc le résultat correct est 9007199254740994.
D'autre part peux-tu m'expliquer
F.7.3 Execution
[#1] At program startup the floating-point environment is initialized as prescribed by IEC 60559: [couic] -- The dynamic rounding precision mode (if supported) is set so that results are not shortened.
C'est à dire que si on fait double + double, on ne doit pas se retrouver avec de la simple précision.
Est-ce que par hasard le mode de précision dynamique a un rapport, même lointain, avec le contrôle de précision du x87?
Et à propos, que vaut sizeof(double_t) ? 8 (=> calculs en 53 bits), ou 10/12/16 (=> calculs en 64 bits) ?
D'abord, tout dépend de la taille d'un char. :) Tout dépend aussi de FLT_EVAL_METHOD.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Bertrand Mollinier Toublet
Antoine Leca wrote:
le sujet, ils ont peut-être tord...
J'ai peut-etre tort, mais il me semble bien que l'orthographe correcte
est bien tor_t_ avec un t et non tor_d_ avec un d.
-- Bertrand Mollinier Toublet "Allo, ici Dupond. Non ! Dupond avec un d, pas Dupont avec un t."
Antoine Leca wrote:
le sujet, ils ont peut-être tord...
J'ai peut-etre tort, mais il me semble bien que l'orthographe correcte
est bien tor_t_ avec un t et non tor_d_ avec un d.
--
Bertrand Mollinier Toublet
"Allo, ici Dupond. Non ! Dupond avec un d, pas Dupont avec un t."
J'ai peut-etre tort, mais il me semble bien que l'orthographe correcte
est bien tor_t_ avec un t et non tor_d_ avec un d.
-- Bertrand Mollinier Toublet "Allo, ici Dupond. Non ! Dupond avec un d, pas Dupont avec un t."
Antoine Leca
Éric Lévénez écrivit:
À propos de ce thread, j'ai toujours entendu dire que la gestion des flottants des pentiums et en particulier des extensions SSE n'étaient pas très standard contrairement aux PPC, y compris avec Altivec.
Je ne voudrais pas mettre de l'huile sur le feu, mais « pas très standard », ce n'est pas absolu, comme définition, il faudrait précisé un peu par rapport à quoi.
D'ailleurs, certains disent que « par définition » ou presque, le Pentium est conforme à IEEE 754... http://www.fi.netbsd.org/People/Pages/ross-essays.html#ieee-754
Tout cela pour dire que (comme d'habitude) il n'est pas impossible que certains se complaisent à répandre une information de dérive par rapport « au standard » du leader (surtout les hégémoniques). Information à prendre avec des pincettes, sinon c'est la guerre (sans aucun intérêt) à celui qui fait le plus de bruit, avec aucun signal à se mettre sous la dent.
(Sans compter que certains persiflent en disant que le standard, et j'emploie le mot français ici, par définition, c'est Intel, au moins en parts de marché.)
Antoine
Éric Lévénez écrivit:
À propos de ce thread, j'ai toujours entendu dire que la gestion des
flottants des pentiums et en particulier des extensions SSE n'étaient
pas très standard contrairement aux PPC, y compris avec Altivec.
Je ne voudrais pas mettre de l'huile sur le feu, mais « pas très
standard », ce n'est pas absolu, comme définition, il faudrait
précisé un peu par rapport à quoi.
D'ailleurs, certains disent que « par définition » ou presque, le
Pentium est conforme à IEEE 754...
http://www.fi.netbsd.org/People/Pages/ross-essays.html#ieee-754
Tout cela pour dire que (comme d'habitude) il n'est pas impossible
que certains se complaisent à répandre une information de dérive
par rapport « au standard » du leader (surtout les hégémoniques).
Information à prendre avec des pincettes, sinon c'est la guerre
(sans aucun intérêt) à celui qui fait le plus de bruit, avec aucun
signal à se mettre sous la dent.
(Sans compter que certains persiflent en disant que le standard,
et j'emploie le mot français ici, par définition, c'est Intel, au moins
en parts de marché.)
À propos de ce thread, j'ai toujours entendu dire que la gestion des flottants des pentiums et en particulier des extensions SSE n'étaient pas très standard contrairement aux PPC, y compris avec Altivec.
Je ne voudrais pas mettre de l'huile sur le feu, mais « pas très standard », ce n'est pas absolu, comme définition, il faudrait précisé un peu par rapport à quoi.
D'ailleurs, certains disent que « par définition » ou presque, le Pentium est conforme à IEEE 754... http://www.fi.netbsd.org/People/Pages/ross-essays.html#ieee-754
Tout cela pour dire que (comme d'habitude) il n'est pas impossible que certains se complaisent à répandre une information de dérive par rapport « au standard » du leader (surtout les hégémoniques). Information à prendre avec des pincettes, sinon c'est la guerre (sans aucun intérêt) à celui qui fait le plus de bruit, avec aucun signal à se mettre sous la dent.
(Sans compter que certains persiflent en disant que le standard, et j'emploie le mot français ici, par définition, c'est Intel, au moins en parts de marché.)
Antoine
Vincent Lefevre
Dans l'article <bh8ft9$tbb$, Antoine Leca écrit:
Vincent Lefevre écrivit: [snip parties peu importantes]
-- The +, -, *, and / operators provide the IEC 60559 add, subtract, multiply, and divide operations.
Bon, là on parle de x+y (dans ton source). Cf. H.2.3.2. Notons (parec que sinon, c'est un dialogue de sourd) que z = x + y, c'est *deux* opérations, une addition suivie d'un stockage,
Oui. Alors concentrons-nous sur l'addition elle-même.
qui comme il est précisé en 6.5.16p2 implique une conversion, couvert par d'autres clauses de IEC 60559.
donc arrondi exact en double précision (la destination est un double).
Ah bon ? Pour moi, la destination est un double_t (je sais, ce n'est pas écrit clairement dans la norme, c'est plutôt l'intention qui compte...)
OK, je m'étais basé sur le fait que type = destination et suivant:
[#2] The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the type; the types are not changed thereby.45)
En fait, la norme IEEE 754 définit le mot "destination" et ce serait le format/représentation des résultats intermédiaires et non leur type. Je suis maintenant d'accord avec toi sur ce point.
Maintenant question: dans le cas d'une précision étendue, est-ce qu'il est autorisé de transformer le résultat en double à l'intérieur d'une sous-expression?
Par exemple, dans
r = (x + y) + z;
est-ce que la deuxième addition doit être effectuée avec x + y en précision étendue (d'origine) ou est-ce que la valeur de x + y peut être convertie en double précision avant l'addition?
Pour faire cultivé, j'ai déniché cette altercation (l'identité des interlocuteurs est un poème en soi...) http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00431.html À ce que j'en comprend, il y a des cas où gcc (au moins les versions d'il y a longtemps) se prend les pieds dans le tapis ;
Je n'ai rien vu indiquant cela dans ce message (mais je suis un peu fatigué...). En revanche, le fait que gcc n'effectue pas de conversion quand on stocke une valeur dans une variable ou qu'on fait un cast (sauf si -ffloat-store est utilisé) est vraiment un bug.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <bh8ft9$tbb$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
Vincent Lefevre écrivit:
[snip parties peu importantes]
-- The +, -, *, and / operators provide the IEC 60559 add,
subtract, multiply, and divide operations.
Bon, là on parle de x+y (dans ton source). Cf. H.2.3.2.
Notons (parec que sinon, c'est un dialogue de sourd) que z = x + y,
c'est *deux* opérations, une addition suivie d'un stockage,
Oui. Alors concentrons-nous sur l'addition elle-même.
qui comme il est précisé en 6.5.16p2 implique une conversion,
couvert par d'autres clauses de IEC 60559.
donc arrondi exact en double précision (la destination est un double).
Ah bon ?
Pour moi, la destination est un double_t (je sais, ce n'est pas écrit
clairement dans la norme, c'est plutôt l'intention qui compte...)
OK, je m'étais basé sur le fait que type = destination et suivant:
[#2] The values of floating operands and of the results of
floating expressions may be represented in greater precision
and range than that required by the type; the types are not
changed thereby.45)
En fait, la norme IEEE 754 définit le mot "destination" et ce serait le
format/représentation des résultats intermédiaires et non leur type. Je
suis maintenant d'accord avec toi sur ce point.
Maintenant question: dans le cas d'une précision étendue, est-ce qu'il
est autorisé de transformer le résultat en double à l'intérieur d'une
sous-expression?
Par exemple, dans
r = (x + y) + z;
est-ce que la deuxième addition doit être effectuée avec x + y en
précision étendue (d'origine) ou est-ce que la valeur de x + y peut
être convertie en double précision avant l'addition?
Pour faire cultivé, j'ai déniché cette altercation (l'identité des
interlocuteurs est un poème en soi...)
http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00431.html
À ce que j'en comprend, il y a des cas où gcc (au moins les
versions d'il y a longtemps) se prend les pieds dans le tapis ;
Je n'ai rien vu indiquant cela dans ce message (mais je suis un
peu fatigué...). En revanche, le fait que gcc n'effectue pas de
conversion quand on stocke une valeur dans une variable ou qu'on
fait un cast (sauf si -ffloat-store est utilisé) est vraiment un
bug.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Vincent Lefevre écrivit: [snip parties peu importantes]
-- The +, -, *, and / operators provide the IEC 60559 add, subtract, multiply, and divide operations.
Bon, là on parle de x+y (dans ton source). Cf. H.2.3.2. Notons (parec que sinon, c'est un dialogue de sourd) que z = x + y, c'est *deux* opérations, une addition suivie d'un stockage,
Oui. Alors concentrons-nous sur l'addition elle-même.
qui comme il est précisé en 6.5.16p2 implique une conversion, couvert par d'autres clauses de IEC 60559.
donc arrondi exact en double précision (la destination est un double).
Ah bon ? Pour moi, la destination est un double_t (je sais, ce n'est pas écrit clairement dans la norme, c'est plutôt l'intention qui compte...)
OK, je m'étais basé sur le fait que type = destination et suivant:
[#2] The values of floating operands and of the results of floating expressions may be represented in greater precision and range than that required by the type; the types are not changed thereby.45)
En fait, la norme IEEE 754 définit le mot "destination" et ce serait le format/représentation des résultats intermédiaires et non leur type. Je suis maintenant d'accord avec toi sur ce point.
Maintenant question: dans le cas d'une précision étendue, est-ce qu'il est autorisé de transformer le résultat en double à l'intérieur d'une sous-expression?
Par exemple, dans
r = (x + y) + z;
est-ce que la deuxième addition doit être effectuée avec x + y en précision étendue (d'origine) ou est-ce que la valeur de x + y peut être convertie en double précision avant l'addition?
Pour faire cultivé, j'ai déniché cette altercation (l'identité des interlocuteurs est un poème en soi...) http://gcc.gnu.org/ml/gcc-patches/2001-03/msg00431.html À ce que j'en comprend, il y a des cas où gcc (au moins les versions d'il y a longtemps) se prend les pieds dans le tapis ;
Je n'ai rien vu indiquant cela dans ce message (mais je suis un peu fatigué...). En revanche, le fait que gcc n'effectue pas de conversion quand on stocke une valeur dans une variable ou qu'on fait un cast (sauf si -ffloat-store est utilisé) est vraiment un bug.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Vincent Lefevre
Dans l'article <BB5DC471.50C46%, Éric Lévénez écrit:
J'ai un exemple concret : NeXTSTEP sur Intel. Ce système marche très bien et utilise beaucoup les calculs flottants pour Display PostScript. Avec un émulateur VirtualPC au dessus d'un PPC le système marche toujours mais certains graphiques sont incorrects. Les instructions fp Intel sont transformés directement en fp pour PPC et cela entraîne ces problèmes. Les 2 étant sensé respecter les normes, l'un doit avoir plus raison que l'autre.
Un programme de test en C devrait pouvoir le dire je suppose.
Le problème est que compte tenu des normes C et IEEE 754, la portabilité n'est pas assurée par défaut. C'est dommage...
Évidemment, un véritable émulateur doit tenir compte de ces différences.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <BB5DC471.50C46%eric@levenez.com>,
Éric Lévénez <eric@levenez.com> écrit:
J'ai un exemple concret : NeXTSTEP sur Intel. Ce système marche très bien et
utilise beaucoup les calculs flottants pour Display PostScript. Avec un
émulateur VirtualPC au dessus d'un PPC le système marche toujours mais
certains graphiques sont incorrects. Les instructions fp Intel sont
transformés directement en fp pour PPC et cela entraîne ces problèmes. Les 2
étant sensé respecter les normes, l'un doit avoir plus raison que l'autre.
Un programme de test en C devrait pouvoir le dire je suppose.
Le problème est que compte tenu des normes C et IEEE 754, la
portabilité n'est pas assurée par défaut. C'est dommage...
Évidemment, un véritable émulateur doit tenir compte de ces
différences.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <BB5DC471.50C46%, Éric Lévénez écrit:
J'ai un exemple concret : NeXTSTEP sur Intel. Ce système marche très bien et utilise beaucoup les calculs flottants pour Display PostScript. Avec un émulateur VirtualPC au dessus d'un PPC le système marche toujours mais certains graphiques sont incorrects. Les instructions fp Intel sont transformés directement en fp pour PPC et cela entraîne ces problèmes. Les 2 étant sensé respecter les normes, l'un doit avoir plus raison que l'autre.
Un programme de test en C devrait pouvoir le dire je suppose.
Le problème est que compte tenu des normes C et IEEE 754, la portabilité n'est pas assurée par défaut. C'est dommage...
Évidemment, un véritable émulateur doit tenir compte de ces différences.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Vincent Lefevre
Dans l'article <20030811170932$, Vincent Lefevre <vincent+ écrit:
[Cas où __STDC_IEC_559__ est défini, calcul sur des double avec précision intermédiaire étendue]
Maintenant question: dans le cas d'une précision étendue, est-ce qu'il est autorisé de transformer le résultat en double à l'intérieur d'une sous-expression?
Par exemple, dans
r = (x + y) + z;
est-ce que la deuxième addition doit être effectuée avec x + y en précision étendue (d'origine) ou est-ce que la valeur de x + y peut être convertie en double précision avant l'addition?
ou alors est-ce que le résultat de (a + b) - (a + b) peut être non nul parce que le résultat de la première addition serait arrondi en double précision (double arrondi, donc) mais pas celui de la seconde addition?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <20030811170932$71d8@vinc17.org>,
Vincent Lefevre <vincent+news@vinc17.org> écrit:
[Cas où __STDC_IEC_559__ est défini, calcul sur des double avec
précision intermédiaire étendue]
Maintenant question: dans le cas d'une précision étendue, est-ce qu'il
est autorisé de transformer le résultat en double à l'intérieur d'une
sous-expression?
Par exemple, dans
r = (x + y) + z;
est-ce que la deuxième addition doit être effectuée avec x + y en
précision étendue (d'origine) ou est-ce que la valeur de x + y peut
être convertie en double précision avant l'addition?
ou alors est-ce que le résultat de (a + b) - (a + b) peut être non nul
parce que le résultat de la première addition serait arrondi en double
précision (double arrondi, donc) mais pas celui de la seconde addition?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <20030811170932$, Vincent Lefevre <vincent+ écrit:
[Cas où __STDC_IEC_559__ est défini, calcul sur des double avec précision intermédiaire étendue]
Maintenant question: dans le cas d'une précision étendue, est-ce qu'il est autorisé de transformer le résultat en double à l'intérieur d'une sous-expression?
Par exemple, dans
r = (x + y) + z;
est-ce que la deuxième addition doit être effectuée avec x + y en précision étendue (d'origine) ou est-ce que la valeur de x + y peut être convertie en double précision avant l'addition?
ou alors est-ce que le résultat de (a + b) - (a + b) peut être non nul parce que le résultat de la première addition serait arrondi en double précision (double arrondi, donc) mais pas celui de la seconde addition?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
