Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

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

5 réponses
Avatar
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.

5 réponses

Avatar
Vincent Lefevre
Bonjour,

Dans l'article <4bb6c33d$0$28966$,
Vincent Belaïche écrit:

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 - Web: <http://www.vinc17.net/&gt;
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/&gt;
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Avatar
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?

Vincent.



Vincent Lefevre a écrit :
Bonjour,

Dans l'article <4bb6c33d$0$28966$,
Vincent Belaïche écrit:

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.

Avatar
Vincent Lefevre
Dans l'article <4bbce6f5$0$2946$,
Vincent Belaïche écrit:

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 - Web: <http://www.vinc17.net/&gt;
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/&gt;
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Avatar
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

(ligne 1445)

Vincent.

Vincent Lefevre a écrit :
Dans l'article <4bbce6f5$0$2946$,
Vincent Belaïche écrit:

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).

Avatar
Vincent Lefevre
Dans l'article ,
Vincent Belaïche écrit:

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 - Web: <http://www.vinc17.net/&gt;
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/&gt;
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)