La méthode suivante à un comportement bizarre:
testReflexion |image| image := b reflectWith: u at: a. self assert: (image x = -2.0 and: [image y = 7.0])
Les tests d'égalité sont false alors que :
"image x" s'évalue à -2.0 (instance de Float)
Idem pour l'autre partie du test.
Une idée de la cause ?
Hilaire
as-tu regarder = sur float pour voir sa definition? float c'est toujours une approximation donc il faut faire attention. Stef
La méthode suivante à un comportement bizarre:
testReflexion |image| image := b reflectWith: u at: a. self assert: (image x = -2.0 and: [image y = 7.0])
Les tests d'égalité sont false alors que :
"image x" s'évalue à -2.0 (instance de Float)
Idem pour l'autre partie du test.
Une idée de la cause ?
Hilaire
-- http://www.ofset.org/petition Pétition de soutien au developpement de logiciels libres pour l'éducation.
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
La méthode suivante à un comportement bizarre:
testReflexion |image| image := b reflectWith: u at: a. self assert: (image x = -2.0 and: [image y = 7.0])
Les tests d'égalité sont false alors que :
"image x" s'évalue à -2.0 (instance de Float)
Je ne connais pas la cause de ton probleme, mais dans la plupart des langages un test d'egalite de float et different d'un test d'égalite d'entiers. En effet, tous les calculs sur les flottants se font avec une certaine precision.
Pour verifier si le probleme vient de la, change ton test en :
(image x - -2.0) abs < 0.001
(verifie la syntaxe)
En fait, le test revient a verifier si les deux nombres sont assez proches pour considerer qu'ils sont egaux. Cette reponse est juste une indiquation et je peux me tromper completement ; je ne connais pas assez Squeak pour etre plus precis.
mais je pense que tu as raison les floats sont "dangereux"
La méthode suivante à un comportement bizarre:
testReflexion |image| image := b reflectWith: u at: a. self assert: (image x = -2.0 and: [image y = 7.0])
Les tests d'égalité sont false alors que :
"image x" s'évalue à -2.0 (instance de Float)
Je ne connais pas la cause de ton probleme, mais dans la plupart des langages un test d'egalite de float et different d'un test d'égalite d'entiers. En effet, tous les calculs sur les flottants se font avec une certaine precision.
Pour verifier si le probleme vient de la, change ton test en :
(image x - -2.0) abs < 0.001
(verifie la syntaxe)
En fait, le test revient a verifier si les deux nombres sont assez proches pour considerer qu'ils sont egaux. Cette reponse est juste une indiquation et je peux me tromper completement ; je ne connais pas assez Squeak pour etre plus precis.
-- Damien _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
L'utilisation de l'epsilon permet de passer le test mais.... Lorsque je deboggue la méthode et que j'inspecte tour à tour "image x" et "-2.0" dans les deux cas l'inspecteur me retourne que les deux objets sont de type float et de valeur -2.0. J'attendrais que l'inspecteur me dise que par exemple "image x" vaut 1.99999. Il semble donc que Squeak se permet quelques libertés d'affichage en arrondissant d'autorité. Depuis un outil de débogguage c'est moyennement appréciable
Je me contenterai donc d'un:
self assert: ((image x closeTo: -2.0) and: [image y closeTo: 7.0])
stéphane ducasse a écrit :
mais je pense que tu as raison les floats sont "dangereux"
La méthode suivante à un comportement bizarre:
testReflexion |image| image := b reflectWith: u at: a. self assert: (image x = -2.0 and: [image y = 7.0])
Les tests d'égalité sont false alors que :
"image x" s'évalue à -2.0 (instance de Float)
Je ne connais pas la cause de ton probleme, mais dans la plupart des langages un test d'egalite de float et different d'un test d'égalite d'entiers. En effet, tous les calculs sur les flottants se font avec une certaine precision.
Pour verifier si le probleme vient de la, change ton test en :
(image x - -2.0) abs < 0.001
(verifie la syntaxe)
En fait, le test revient a verifier si les deux nombres sont assez proches pour considerer qu'ils sont egaux. Cette reponse est juste une indiquation et je peux me tromper completement ; je ne connais pas assez Squeak pour etre plus precis.
-- Damien _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
L'utilisation de l'epsilon permet de passer le test mais.... Lorsque je deboggue la méthode et que j'inspecte tour à tour "image x" et "-2.0" dans les deux cas l'inspecteur me retourne que les deux objets sont de type float et de valeur -2.0. J'attendrais que l'inspecteur me dise que par exemple "image x" vaut 1.99999. Il semble donc que Squeak se permet quelques libertés d'affichage en arrondissant d'autorité. Depuis un outil de débogguage c'est moyennement appréciable
Je pense que c'est une chose generale avec les float, il ne faut pas comparer leur representation graphique avec l'objet. Je ne crois pas que cela soit specifique a Squeak. Qd tu es dans le debuggeur tu vois une **representation*8 des objets ce qui est normal. et pour les floats on est au bord de la metaphore text/objet qui marche tres bien avec les int, bool, string.
par exemple tu pourrais faire image x printString pour comparer la representation textuelle du float avec tous les risques que cela contient
Je me contenterai donc d'un:
self assert: ((image x closeTo: -2.0) and: [image y closeTo: 7.0])
stéphane ducasse a écrit :
mais je pense que tu as raison les floats sont "dangereux"
La méthode suivante à un comportement bizarre:
testReflexion |image| image := b reflectWith: u at: a. self assert: (image x = -2.0 and: [image y = 7.0])
Les tests d'égalité sont false alors que :
"image x" s'évalue à -2.0 (instance de Float)
Je ne connais pas la cause de ton probleme, mais dans la plupart des langages un test d'egalite de float et different d'un test d'égalite d'entiers. En effet, tous les calculs sur les flottants se font avec une certaine precision.
Pour verifier si le probleme vient de la, change ton test en :
(image x - -2.0) abs < 0.001
(verifie la syntaxe)
En fait, le test revient a verifier si les deux nombres sont assez proches pour considerer qu'ils sont egaux. Cette reponse est juste une indiquation et je peux me tromper completement ; je ne connais pas assez Squeak pour etre plus precis.
-- Damien _______________________________________________ Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
-- http://www.ofset.org/petition Pétition de soutien au developpement de logiciels libres pour l'éducation.
Squeak-fr mailing list Squeak-fr@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeak-fr
Le 27 mai 05, à 19:00, Hilaire Fernandes a écrit :
L'utilisation de l'epsilon permet de passer le test mais.... Lorsque je deboggue la méthode et que j'inspecte tour à tour "image x" et "-2.0" dans les deux cas l'inspecteur me retourne que les deux objets sont de type float et de valeur -2.0. J'attendrais que l'inspecteur me dise que par exemple "image x" vaut 1.99999. Il semble donc que Squeak se permet quelques libertés d'affichage en arrondissant d'autorité. Depuis un outil de débogguage c'est moyennement appréciable
Je me contenterai donc d'un:
self assert: ((image x closeTo: -2.0) and: [image y closeTo: 7.0])
En effet, si fait un printIt de : -2.000000000000001 On obtient -2.0 et -2.000000000000001 = -2 retourne false. Le problème ne se produit plus pour : -1.000000000000001 ...
J'imagine que le problème doit se produire dans Float>>absPrintOn: aStream base: base
-- oooo Dr. Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##
squeak-fr@lists.squeakfoundation.org
-
Damien Cassou -
Hilaire Fernandes -
Serge Stinckwich -
stéphane ducasse