Cela tient à la représentation interne des nombres flottants. Si cette représentation donne pour la mantisse un nombre nécessitant un nombre infini de bits (comme quand on calcule 1/3 0.333333...) le résultat utilisant ce nombre dans les calculs sera forcément une valeur approchée.
Pour pallier ce problème, soit tu connais le nombre de décimales de tes données (par exemple dans le cas de la monnaie) et tu travailles en centimes, avec des nombres entiers donc ; soit tu arrondis à la précision voulue le résultat avant affichage.
-- Y.D.
Pourquoi le code suivant m'affiche 0.1999999999999993 et pas 0.20 et comment
obtenir le résultat correct ???
Cela tient à la représentation interne des nombres flottants. Si cette représentation
donne pour la mantisse un nombre nécessitant un nombre infini de bits (comme quand on
calcule 1/3 0.333333...) le résultat utilisant ce nombre dans les calculs sera
forcément une valeur approchée.
Pour pallier ce problème, soit tu connais le nombre de décimales de tes données (par
exemple dans le cas de la monnaie) et tu travailles en centimes, avec des nombres
entiers donc ; soit tu arrondis à la précision voulue le résultat avant affichage.
Cela tient à la représentation interne des nombres flottants. Si cette représentation donne pour la mantisse un nombre nécessitant un nombre infini de bits (comme quand on calcule 1/3 0.333333...) le résultat utilisant ce nombre dans les calculs sera forcément une valeur approchée.
Pour pallier ce problème, soit tu connais le nombre de décimales de tes données (par exemple dans le cas de la monnaie) et tu travailles en centimes, avec des nombres entiers donc ; soit tu arrondis à la précision voulue le résultat avant affichage.
-- Y.D.
BMR
L'erreur est franchement insignifiante ! :-)
Cela tient à la représentation interne des nombres flottants. Si cette représentation donne pour la mantisse un nombre nécessitant un nombre infini de bits (comme quand on calcule 1/3 0.333333...) le résultat utilisant ce nombre dans les calculs sera forcément une valeur approchée.
Pour pallier ce problème, soit tu connais le nombre de décimales de tes données (par exemple dans le cas de la monnaie) et tu travailles en centimes, avec des nombres entiers donc ; soit tu arrondis à la précision voulue le résultat avant affichage.
J'ai posté une solution avec toFixed(2). Mais apparemment ce n'est pas encore en ligne... A ce propos, il y a un bug avec Firefox sur cette fonction (et toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54 par FF et à 158.55 par IE. Un peu génant dans un formulaire de commande, p.ex. Donc j'aimerais connaître la représentation binaire de cette valeur par JS (et en général des valeurs float), ce qui permettrait de trouver les autres valeurs éventuelles qui bugueraient.
BMR
L'erreur est franchement insignifiante ! :-)
Cela tient à la représentation interne des nombres flottants. Si cette
représentation
donne pour la mantisse un nombre nécessitant un nombre infini de bits
(comme quand on
calcule 1/3 0.333333...) le résultat utilisant ce nombre dans les
calculs sera
forcément une valeur approchée.
Pour pallier ce problème, soit tu connais le nombre de décimales de tes
données (par
exemple dans le cas de la monnaie) et tu travailles en centimes, avec
des nombres
entiers donc ; soit tu arrondis à la précision voulue le résultat avant
affichage.
J'ai posté une solution avec toFixed(2). Mais apparemment ce n'est pas
encore en ligne...
A ce propos, il y a un bug avec Firefox sur cette fonction (et
toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54
par FF et à 158.55 par IE. Un peu génant dans un formulaire de commande,
p.ex. Donc j'aimerais connaître la représentation binaire de cette
valeur par JS (et en général des valeurs float), ce qui permettrait de
trouver les autres valeurs éventuelles qui bugueraient.
Cela tient à la représentation interne des nombres flottants. Si cette représentation donne pour la mantisse un nombre nécessitant un nombre infini de bits (comme quand on calcule 1/3 0.333333...) le résultat utilisant ce nombre dans les calculs sera forcément une valeur approchée.
Pour pallier ce problème, soit tu connais le nombre de décimales de tes données (par exemple dans le cas de la monnaie) et tu travailles en centimes, avec des nombres entiers donc ; soit tu arrondis à la précision voulue le résultat avant affichage.
J'ai posté une solution avec toFixed(2). Mais apparemment ce n'est pas encore en ligne... A ce propos, il y a un bug avec Firefox sur cette fonction (et toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54 par FF et à 158.55 par IE. Un peu génant dans un formulaire de commande, p.ex. Donc j'aimerais connaître la représentation binaire de cette valeur par JS (et en général des valeurs float), ce qui permettrait de trouver les autres valeurs éventuelles qui bugueraient.
BMR
BMR
Salut,
Pourquoi le code suivant m'affiche 0.1999999999999993 et pas 0.20 et comment obtenir le résultat correct ???
A ce propos, il y a un bug avec Firefox sur cette fonction (et toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54 par FF et à 158.55 par IE.
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et que IE emploie la vieille méthode, mais la norme EcmaScript est assez obscure et je ne sais pas trop ce qu'elle recommande.
Pour vérifier mon hypothèse, voici différents résultats à tester :
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
A ce propos, il y a un bug avec Firefox sur cette fonction (et
toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54
par FF et à 158.55 par IE.
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et
que IE emploie la vieille méthode, mais la norme EcmaScript est assez
obscure et je ne sais pas trop ce qu'elle recommande.
Pour vérifier mon hypothèse, voici différents résultats à tester :
A ce propos, il y a un bug avec Firefox sur cette fonction (et toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54 par FF et à 158.55 par IE.
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et que IE emploie la vieille méthode, mais la norme EcmaScript est assez obscure et je ne sais pas trop ce qu'elle recommande.
Pour vérifier mon hypothèse, voici différents résultats à tester :
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
YD
A ce propos, il y a un bug avec Firefox sur cette fonction (et toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54 par FF et à 158.55 par IE. Un peu génant dans un formulaire de commande, p.ex. [...]
C'est pourquoi je recommandais dans mon article précédent de travailler avec des entiers dès que possible...
-- Y.D.
A ce propos, il y a un bug avec Firefox sur cette fonction (et
toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54
par FF et à 158.55 par IE. Un peu génant dans un formulaire de commande,
p.ex. [...]
C'est pourquoi je recommandais dans mon article précédent de travailler
avec des entiers dès que possible...
A ce propos, il y a un bug avec Firefox sur cette fonction (et toPrecision(), je crois aussi) sur la valeur 158.545 arrondi à 158.54 par FF et à 158.55 par IE. Un peu génant dans un formulaire de commande, p.ex. [...]
C'est pourquoi je recommandais dans mon article précédent de travailler avec des entiers dès que possible...
-- Y.D.
YD
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et que IE emploie la vieille méthode, mais la norme EcmaScript est assez obscure et je ne sais pas trop ce qu'elle recommande.
Sur le point la norme ECMAScript est franchement claire. Je cite (pas de mémoire :-) )
4.3.20 Number Type The type Number is a set of values representing numbers. In ECMAScript, the set of values represents the double-precision 64-bit format IEEE 754 values including the special "Not-a-Number" (NaN) values, positive infinity, and negative infinity.
Là ça devient pointu pour moi -- je ne connais pas la norme IEEE 754 en question !
-- Y.D.
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et
que IE emploie la vieille méthode, mais la norme EcmaScript est assez
obscure et je ne sais pas trop ce qu'elle recommande.
Sur le point la norme ECMAScript est franchement claire. Je cite (pas de mémoire :-) )
4.3.20 Number Type
The type Number is a set of values representing numbers. In ECMAScript,
the set of values represents the double-precision 64-bit format IEEE 754
values including the special "Not-a-Number" (NaN) values, positive
infinity, and negative infinity.
Là ça devient pointu pour moi -- je ne connais pas la norme IEEE 754 en question !
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et que IE emploie la vieille méthode, mais la norme EcmaScript est assez obscure et je ne sais pas trop ce qu'elle recommande.
Sur le point la norme ECMAScript est franchement claire. Je cite (pas de mémoire :-) )
4.3.20 Number Type The type Number is a set of values representing numbers. In ECMAScript, the set of values represents the double-precision 64-bit format IEEE 754 values including the special "Not-a-Number" (NaN) values, positive infinity, and negative infinity.
Là ça devient pointu pour moi -- je ne connais pas la norme IEEE 754 en question !
-- Y.D.
LR
Salut,
Pourquoi le code suivant m'affiche 0.1999999999999993 et pas 0.20 et comment obtenir le résultat correct ???
Merci pour toutes les réponses, j'ai utilisé Math.round comme ci-dessus et c'est tout bon. A+Lilian
Olivier Miakinen
Le 17/03/2005 22:20, YD me répondait :
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et que IE emploie la vieille méthode, mais la norme EcmaScript est assez obscure et je ne sais pas trop ce qu'elle recommande.
Sur le point la norme ECMAScript est franchement claire. Je cite (pas de mémoire :-) )
4.3.20 Number Type [...]
C'est le paragraphe 15.7.4.5 que je qualifiais d'obscur. Mon terme était d'ailleurs très mal choisi, car il est très clair, mais simplement il faut prendre le temps de dérouler l'algorithme, ce que j'ai fait.
Le point essentiel est le numéro 10 (en supposant x = 158.545, f = 2).
<cit.> 10. Let n be an integer for which the exact mathématical value of n ÷ 10^f - x is as close to zero as possible. If there are two such n, pick the larger n. </cit.>
En l'occurrence, si x était représenté exactement, avec n854 on obtiendrait -0.005, et +0.005 avec n855. Tous deux étant aussi proches de zéro, on choisirait le plus grand, ce qui donnerait n855 et au final le résultat 158.55. Mais avec les approximations de la représentation, peut-être que l'on obtient -0,0049999999 contre +0,0050000001.
Là ça devient pointu pour moi -- je ne connais pas la norme IEEE 754 en question !
Je n'ai pas lu cette norme, mais elle est citée ici, justement à propos de toFixed et des problèmes d'arrondi : http://www.js-examples.com/javascript/ref_js15/number.php#1200964
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Le 17/03/2005 22:20, YD me répondait :
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et
que IE emploie la vieille méthode, mais la norme EcmaScript est assez
obscure et je ne sais pas trop ce qu'elle recommande.
Sur le point la norme ECMAScript est franchement claire. Je cite (pas de mémoire :-) )
4.3.20 Number Type
[...]
C'est le paragraphe 15.7.4.5 que je qualifiais d'obscur. Mon terme était
d'ailleurs très mal choisi, car il est très clair, mais simplement il
faut prendre le temps de dérouler l'algorithme, ce que j'ai fait.
Le point essentiel est le numéro 10 (en supposant x = 158.545, f = 2).
<cit.>
10. Let n be an integer for which the exact mathématical value of
n ÷ 10^f - x is as close to zero as possible. If there are two such n,
pick the larger n.
</cit.>
En l'occurrence, si x était représenté exactement, avec n854 on
obtiendrait -0.005, et +0.005 avec n855. Tous deux étant aussi
proches de zéro, on choisirait le plus grand, ce qui donnerait n855
et au final le résultat 158.55. Mais avec les approximations de la
représentation, peut-être que l'on obtient -0,0049999999 contre
+0,0050000001.
Là ça devient pointu pour moi -- je ne connais pas la norme IEEE 754 en question !
Je n'ai pas lu cette norme, mais elle est citée ici, justement à propos
de toFixed et des problèmes d'arrondi :
http://www.js-examples.com/javascript/ref_js15/number.php#1200964
--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.
Cela pourrait être parce que Firefox respecte la norme IEEE-754 et que IE emploie la vieille méthode, mais la norme EcmaScript est assez obscure et je ne sais pas trop ce qu'elle recommande.
Sur le point la norme ECMAScript est franchement claire. Je cite (pas de mémoire :-) )
4.3.20 Number Type [...]
C'est le paragraphe 15.7.4.5 que je qualifiais d'obscur. Mon terme était d'ailleurs très mal choisi, car il est très clair, mais simplement il faut prendre le temps de dérouler l'algorithme, ce que j'ai fait.
Le point essentiel est le numéro 10 (en supposant x = 158.545, f = 2).
<cit.> 10. Let n be an integer for which the exact mathématical value of n ÷ 10^f - x is as close to zero as possible. If there are two such n, pick the larger n. </cit.>
En l'occurrence, si x était représenté exactement, avec n854 on obtiendrait -0.005, et +0.005 avec n855. Tous deux étant aussi proches de zéro, on choisirait le plus grand, ce qui donnerait n855 et au final le résultat 158.55. Mais avec les approximations de la représentation, peut-être que l'on obtient -0,0049999999 contre +0,0050000001.
Là ça devient pointu pour moi -- je ne connais pas la norme IEEE 754 en question !
Je n'ai pas lu cette norme, mais elle est citée ici, justement à propos de toFixed et des problèmes d'arrondi : http://www.js-examples.com/javascript/ref_js15/number.php#1200964
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
