Version imprimable
Bonjour,
Je suis tombé sur ce qui ressemble bien à un bug de calcul que je ne sais expliquer :
8O :calim2:Citation:
alert(13000000000000000 + 4); //=> 13000000000000004
alert(13000000000000000 + 5); //=> 13000000000000004
alert(13000000000000000 + 6); //=> 13000000000000006
Firefox 3.0.11 et IE7. Dual-core T2080.
Firefox 3.0.11, Mac PowerPC G4
Quelqu'un a une idée ?
Merci.
C'est normal ça vient de la représentation utilisé par JS des nombres (flottants, ils le sont tous en JS, il n'y a pas «d'integer»).
Y'a rien ou pas grand chose à faire ^^.
Salut,
+1 nod__
Pour compléter, ce n'est d'ailleurs pas qu'un problème lié à JS, mais plus généralement à tous les calculs faits en virgule flottante. En gros un nombre est stocké sous la forme 1.xxxxxxx * 2^n , avec xxxxx la précision. Or cette dernière n'est pas extensible (15 chiffres avec un réel stocké sur 64bits) Moralité, si on ajoute un très petit nombre à un très grand nombre, le résultat peut être uniquement le très grands nombre. :aie: Ceux qui ont l'habitude de travailler avec de tels nombres savent gérer ces taux d'erreur, ou calculent autrement.
Note enfin que de la même manière il est impossible de codifier exactement certains nombres tel que 0.1; de là: 0.1 * 0.196 = 0.019600000000000003, ce qui laisse augurer des affichages étranges lors des calculs de TVA par exemple...
ERE
Salut,
Pour palier à ce problème, il faut imposer à JS de travailler en virgule fixe,
Code:
2
3
4
Ça c'est fun. Je pensais que toFixed renvoyais tout le temps une chaine, ben je me suis gourré.
Par contre faut faire gaffe, en passant 1 ou plus en argument on récupère une chaine et là… ça calcule comme je parle allemand… :aie:
C'est normal, c'est normal... Si vous me le dites. :mouarf:
Pourtant :
(13000000000000000 + 5) < Number.MAX_VALUE => true
Number.MAX_VALUE = 1.7976931348623157e+308
Le mieux qu'il peut afficher en entier : alert(1.7976931348623157e+20)
Au delà, JS passe par la notation 'e+'.
Mais ok pour la représentation, mais ça ne va pas être simple :
alert(1.0e+15 + 5) //=> 1000000000000005 ok !
alert(13 * 1.0e+15) //=> 1300000000000000 ok !
alert(13 * 1.0e+15 + 5) //=> 1300000000000004 KO
alert(1.3e+16 + 5) //=> 1300000000000004 KO
alert((1.3e+16) + 5.0) //=> 1300000000000004 KO
alert((1.3e+16) + 0.5e+1) //=> 1300000000000004 KO
alert(new Number( 1.3e+16) + new Number(0.5e+1)) //=> KO
alert(new Number( 1.3e+16 + 0.5e+1)) //=> KO
A ce stade, je me dis que si Number permet de représenter de très grands nombres, il ne permet pas de les additionner.
Et même avec ça :
alert((1.3 + (0.5/1.0e+15)) * 1.0e+16) //=> KO !
C'est pas beaucoup mieux. Le résultat est finalement très hasardeux.
J'essaie une ruse :
alert(((13.0 * 1.0e+15)/1.0e+8) + (0.5e+1/1.0e+8)) //=>130000000.00000004
Pas mieux...
J'ai l'impression que je vais devoir me créer une classe BigInteger... :cry:
Moi qui croyait qu'on était passé à l'air du 64 bits et vu que des procs 128 bits arrivent. C'est encore les FPUs qui trainent.
Merci à vous.
Ah................... :ccool:Citation:
Envoyé par marcha
Merci.
j'avais oublié le toFixed ^^
j'en étais rendu à trouver une affreuse bidouille :
qui en fait revient au même puisqu'elle sort des virgules flottantes ...Code:
2
3
4
5
Arf... C'était trop beau pour être vrai.
L'utilisation de Math (en l'occurrence Math.max()) me bouffe l'unité.
Pour cause :
alert((13000000000000000).toFixed(0) + 5);
Aurait pu être bien, mais il s'agit d'une concaténation, pas d'une addition.
Arg, mea culpa, j'en ai fait une bien grosse là :-)
D'autres s'y sont attelés ;) : http://silentmatt.com/biginteger/ , http://www.onicos.com/staff/iz/amuse...ert/BigInt.txtCitation:
Envoyé par kernelfailure
ERE
Oui, j'ai vu ça (le premier liens). C'est pas mal complexe tout ça.Citation:
Envoyé par emmanuel.remy
N'ayant pas trouvé une qui me plaise, je viens de terminer une petite classe qui suffit à mon besoin (add(), mul(), min(), max()).
Entier strictement positif pour le moment.
Merci ;)