Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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.
Dans l'article <4bb6c33d$0$28966$ba4acef3@reader.news.orange.fr>,
Vincent Belaïche <vincent.belaiche@gmail.com> é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.
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.
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.
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$ba4acef3@reader.news.orange.fr>,
Vincent Belaïche <vincent.belaiche@gmail.com> é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.
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.
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).
Dans l'article <4bbce6f5$0$2946$ba4acef3@reader.news.orange.fr>,
Vincent Belaïche <vincent.belaiche@gmail.com> é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).
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).
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
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).
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
Dans l'article <4bbce6f5$0$2946$ba4acef3@reader.news.orange.fr>,
Vincent Belaïche <vincent.belaiche@gmail.com> é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).
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
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 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
Dans l'article <4BBF8BF5.7080701@gmail.com>,
Vincent Belaïche <vincent.belaiche@gmail.com> é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
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