-0x.p0 a-t-il toujours un bit de sign à 1

Le
Vincent Belaïche
Bonjour,

Avec gcc le bit de sign de -0x.p0 est à 1, comme celui de -0.0 d'ailleurs.

Est-ce un comportement garanti, ou bien est-ce qu'un compilateur à la
droit de remplacer -0.0 par 0.0.

Vincent.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Vincent Lefevre
Le #21488582
Bonjour,

Dans l'article Vincent Belaïche
Avec gcc le bit de sign de -0x.p0 est à 1, comme celui de -0.0 d'ailleurs.

Est-ce un comportement garanti, ou bien est-ce qu'un compilateur à la
droit de remplacer -0.0 par 0.0.



En C, le zéro flottant peut être signé ou non; il doit l'être si
l'annexe F est supportée (ce qui n'est pas forcément le cas, même
si le processeur supporte la norme IEEE 754-1985).

Si le zéro flottant est signé, alors le compilateur doit conserver
son signe.

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Vincent Belaïche
Le #21515852
Question subsidiaire:

la version d'emacs que j'utilise contient la ligne de code C suivante

#define XFLOAT_DATA(f) (XFLOAT (f)->u.data + 0)

cela a pour effet qu'à chaque fois qu'un flottant Lisp (équivalent à un
double en C) est évalué, sa valeur est normalisée de sorte que

-0.0 devient 0.0
NaN prend une valeur en mémoire par défaut

Je ne connais pas la motivation de ce truc, mais je suppose que l'effet
voulu et que si deux float Lisp sont eq (=identitiques en mémoire) alors
il sont equal (de même valeur) et vice-versa.

La question subsidiaire est la suivante: l'implantation courante
d'emacs-lisp à laquelle je me réfère est-elle conforme à l'IEEE754?

Vincent.



Vincent Lefevre a écrit :
Bonjour,

Dans l'article Vincent Belaïche
Avec gcc le bit de sign de -0x.p0 est à 1, comme celui de -0.0 d'ailleurs.



Est-ce un comportement garanti, ou bien est-ce qu'un compilateur à la
droit de remplacer -0.0 par 0.0.



En C, le zéro flottant peut être signé ou non; il doit l'être si
l'annexe F est supportée (ce qui n'est pas forcément le cas, même
si le processeur supporte la norme IEEE 754-1985).

Si le zéro flottant est signé, alors le compilateur doit conserver
son signe.

Vincent Lefevre
Le #21516882
Dans l'article Vincent Belaïche
Question subsidiaire:

la version d'emacs que j'utilise contient la ligne de code C suivante

#define XFLOAT_DATA(f) (XFLOAT (f)->u.data + 0)

cela a pour effet qu'à chaque fois qu'un flottant Lisp (équivalent à un
double en C) est évalué, sa valeur est normalisée de sorte que

-0.0 devient 0.0
NaN prend une valeur en mémoire par défaut

Je ne connais pas la motivation de ce truc, mais je suppose que l'effet
voulu et que si deux float Lisp sont eq (=identitiques en mémoire) alors
il sont equal (de même valeur) et vice-versa.

La question subsidiaire est la suivante: l'implantation courante
d'emacs-lisp à laquelle je me réfère est-elle conforme à l'IEEE754?



Pour être conforme à la norme IEEE 754, il faut supporter les modes
d'arrondi requis, et l'astuce ci-dessus ne fonctionne plus en arrondi
vers -inf, ou il faudrait forcer l'opération ci-dessus à être faite
en arrondi au plus près (malheureusement en C, ce n'est pas exprimable
simplement).

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Vincent Belaïche
Le #21526921
Peux-tu juste me donner un exemple d'une opération dont le résultat
diffère entre le cas conforme et le cas avec l'astuce en question.

Je suppose qu'il s'agit de (/ 1.0 (- 0.0)) qui donne 1.0e+INF au lieu de
-1.0e+INF.

je précise que j'ai testé avec Emacs 23.1.1. (dernière version binaire
téléchargeable pour Windows) et que ça fait bien -1.0e+INF, le problème
semble relativement récent: c'est avec la dernière version de
développement dans le référentiel

http://git.savannah.gnu.org/cgit/emacs.git/tree/src/lisp.h

(ligne 1445)

Vincent.

Vincent Lefevre a écrit :
Dans l'article Vincent Belaïche
Question subsidiaire:



la version d'emacs que j'utilise contient la ligne de code C suivante



#define XFLOAT_DATA(f) (XFLOAT (f)->u.data + 0)



cela a pour effet qu'à chaque fois qu'un flottant Lisp (équivalent à un
double en C) est évalué, sa valeur est normalisée de sorte que



-0.0 devient 0.0
NaN prend une valeur en mémoire par défaut



Je ne connais pas la motivation de ce truc, mais je suppose que l'effet
voulu et que si deux float Lisp sont eq (=identitiques en mémoire) alors
il sont equal (de même valeur) et vice-versa.



La question subsidiaire est la suivante: l'implantation courante
d'emacs-lisp à laquelle je me réfère est-elle conforme à l'IEEE754?



Pour être conforme à la norme IEEE 754, il faut supporter les modes
d'arrondi requis, et l'astuce ci-dessus ne fonctionne plus en arrondi
vers -inf, ou il faudrait forcer l'opération ci-dessus à être faite
en arrondi au plus près (malheureusement en C, ce n'est pas exprimable
simplement).

Vincent Lefevre
Le #21527441
Dans l'article Vincent Belaïche
Peux-tu juste me donner un exemple d'une opération dont le résultat
diffère entre le cas conforme et le cas avec l'astuce en question.

Je suppose qu'il s'agit de (/ 1.0 (- 0.0)) qui donne 1.0e+INF au lieu de
-1.0e+INF.

je précise que j'ai testé avec Emacs 23.1.1. (dernière version binaire
téléchargeable pour Windows) et que ça fait bien -1.0e+INF, le problème
semble relativement récent: c'est avec la dernière version de
développement dans le référentiel

http://git.savannah.gnu.org/cgit/emacs.git/tree/src/lisp.h



Je pense qu'Emacs 23.1.1 est "trop vieux": le + 0 date du 17 août.
D'ailleurs

http://git.savannah.gnu.org/cgit/emacs.git/tree/src/lisp.h?h=EMACS_23_1_RC

indique:

#define XFLOAT_DATA(f) (XFLOAT (f)->u.data)

J'ai envoyé un mail sur la liste bug-gnu-emacs pour signaler le
problème.

--
Vincent Lefèvre 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Publicité
Poster une réponse
Anonyme