Celui a fait qu'ils l'ont appele pentium et pas 586, parce qu'ils ont fait l'operation 486 + 100 avec et que le resultat de 485.999999999999 ne leur paraissait pas tres bon niveau marketing ?
C'est tout à fait normal et pas forcément lié à java : ta précision est de 9.37-9.3699999999999 , soit pas beaucoup. Les calculs en nb flottants sont de toutes manières approchés (le nombre de valeurs possibles étant fini). Après, si tu veux en faire un affichage correct (écrire X+1 au lieu de X.999999999999), tu peux écrire une fonction adaptée.
En fait c'est pas tant le fait que le nombre de combinaisons soit limité qui pose problème dans le cas précis, mais celui qu'un nombre peut être fini dans une base et pas dans une autre.
Exemple:
1.5d = 1.1b
1.2d = 1.0011001100110011 ...
L'arrondi se fait probablement, dans ton cas, en fonction de la valeur du dernier bit du champs (le bit de poids faible de la mantisse, à droite) qui ici doit probablement être à 1. Quand tu multiples par 100, tu introduis probablement des zéros à la fin de ta mantisse, qui du coup doit être arrondi au plus faible. Il existe plusieurs manières de traiter cela. Quoiqu'il en soit, tu dois bien avoir un fonction round() qui sert à gérer cela (je connais pas le Java).
Tout-à-fait, l'exemple 1/3 est l'exemple de nombre non-fini le plus courant en maths, mais il s'agissait de donner l'exemple de quelque chose qui provoque ce cas en binaire et qui provoque potentiellement une erreur avec les nombres à virgule flottante.
De plus, 1.5 et 1.2 sont non seulement deux nombres finis en décimal, mais qui en plus ont l'air très faciles à coder. Qui aurait crû qu'un ordinateur ne peut exactement se représenter 1.2 ? :-)
Si tu y arrives, je te files un prix nobel.
Regardez la puissance de Microsoft ! Chacun de leurs employés peut délivrer un prix Nobel. Après on nous traite de paranos :-)
Ni d'ailleurs le C, le C++ etc ...
Bref, faut juste savoir qu'un double ne peut prendre qu'un ensemble de valeurs finies, et donc va faire loger un resultat theorique dans la valeur la plus proche qu'il peut representer ...
Un gros problème de pas mal de bibliothèques numériques et de processeurs, c'est qu'ils sont optimisés surtout pour la vitesse. Résultat, ils ne garantissent absolument rien sur la précision du résultat. Il est très fréquent de perdre 5 bits de précision sur une division. Il existe une norme IEEE qui spécifie l'addition, la soustraction, la multiplication et la division mais rien de plus et peu de processeurs l'implémentent parfaitement.
Bizarre, ça marche en C (VC6 et gcc), mais pas en Python. Pourtant j'ai viré l'optimisation... J'ai pas envie de faire la conversion à la main (mantisse, exposant, signe) qui est laissée comme exercice au lecteur :-)
Ce n'est pas que un problème de précision, mais aussi d'affichage. Ne fais pas un System.out.println("valeur=" + nb), mais utilise un formateur. Je te laisse chercher dans la javadoc comment faire...
...
double nb = 9.37;
System.out.println(nb);
nb = nb * 100;
DecimalFormat decimalFormat = new DecimalFormat();
System.out.println(decimalFormat.format(nb));
...
Pour être vachement plus précis, tu as le BigDecimal (ds java.math) :
BigDecimal nb = new BigDecimal(9.37);
BigDecimal cent = new BigDecimal(100);
nb = nb.mutliply(cent);
-> nb.toString() donne 937.000
(BigDecimal accepte des double ou des String dans son contructeur)
# Re: Java et les double
Posté par Bruno Stévant (site web personnel) . Évalué à 3.
===>[]
[^] # Re: Java et les double
Posté par Clem Yeats . Évalué à 1.
Est-ce lie au processeur ? La javadoc semble indiquer que les doubles ne garantissent pas la precision..
[^] # Re: Java et les double
Posté par Ramso . Évalué à 2.
[^] # Re: Java et les double
Posté par imalip . Évalué à 2.
# Re: Java et les double
Posté par Nap . Évalué à 10.
tout ça me fait penser à un personnage clé de DLFP
[^] # Re: Java et les double
Posté par \o/ . Évalué à 3.
[^] # Re: Java et les double
Posté par MagicNinja . Évalué à 3.
# Re: Java et les double
Posté par gawal . Évalué à 4.
[^] # Re: Java et les double
Posté par Obsidian . Évalué à 6.
Exemple:
1.5d = 1.1b
1.2d = 1.0011001100110011 ...
L'arrondi se fait probablement, dans ton cas, en fonction de la valeur du dernier bit du champs (le bit de poids faible de la mantisse, à droite) qui ici doit probablement être à 1. Quand tu multiples par 100, tu introduis probablement des zéros à la fin de ta mantisse, qui du coup doit être arrondi au plus faible. Il existe plusieurs manières de traiter cela. Quoiqu'il en soit, tu dois bien avoir un fonction round() qui sert à gérer cela (je connais pas le Java).
[^] # Re: Java et les double
Posté par fmaz fmaz . Évalué à 3.
1/3=0.33333333333333333333333333.... en base 10
1/3=.1 en base 3
[^] # Re: Java et les double
Posté par Obsidian . Évalué à 3.
De plus, 1.5 et 1.2 sont non seulement deux nombres finis en décimal, mais qui en plus ont l'air très faciles à coder. Qui aurait crû qu'un ordinateur ne peut exactement se représenter 1.2 ? :-)
# Re: Java et les double
Posté par pasBill pasGates . Évalué à 5.
Trouves moi un moyen de representer dans un champs de disons 32bits, toutes les valeurs 0 a 1.
0.1, 0.01, 0.0003, 0.000000005, etc....
Si tu y arrives, je te files un prix nobel.
Si tu n'y arrives pas, ben tu auras compris pourquoi Java n'y arrive pas non plus
[^] # Re: Java et les double
Posté par Fabimaru (site web personnel) . Évalué à 6.
Regardez la puissance de Microsoft ! Chacun de leurs employés peut délivrer un prix Nobel. Après on nous traite de paranos :-)
[^] # Re: Java et les double
Posté par Epsos . Évalué à 1.
Bref, faut juste savoir qu'un double ne peut prendre qu'un ensemble de valeurs finies, et donc va faire loger un resultat theorique dans la valeur la plus proche qu'il peut representer ...
[^] # Re: Java et les double
Posté par fmaz fmaz . Évalué à 3.
Un gros problème de pas mal de bibliothèques numériques et de processeurs, c'est qu'ils sont optimisés surtout pour la vitesse. Résultat, ils ne garantissent absolument rien sur la précision du résultat. Il est très fréquent de perdre 5 bits de précision sur une division. Il existe une norme IEEE qui spécifie l'addition, la soustraction, la multiplication et la division mais rien de plus et peu de processeurs l'implémentent parfaitement.
[^] # Re: Java et les double
Posté par Jean-Marc Spaggiari . Évalué à 1.
Il n'arrondit pas, mais qu'est-ce qu'il est lent ;)
# Re: Java et les double
Posté par vrm (site web personnel) . Évalué à 3.
Fais le test en C
[^] # Re: Java et les double
Posté par kesako . Évalué à 1.
> perl -e '$nb=9.37; $nb*=100; print $nb;'
937
[^] # Re: Java et les double
Posté par xilun . Évalué à 1.
[^] # Re: Java et les double
Posté par philz . Évalué à 2.
perl -e '$nb=9.37; $nb*=100; printf "%.15f", $nb;'
936.999999999999886
[^] # Re: Java et les double
Posté par jigso . Évalué à 2.
Perl fait ce qu'on attend, pas ce que la machine veut bien faire. C'est en ça que c'est un langage génial...
[^] # Re: Java et les double
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Re: Java et les double
Posté par Ramso . Évalué à 1.
Qui d'ailleurs peuvent intéresser les autres.
[^] # Re: Java et les double
Posté par Vivi (site web personnel) . Évalué à 2.
[^] # Re: Java et les double
Posté par hex . Évalué à 1.
#include <iostream> int main() { float f = 9.37f; double d = 9.37; f = f * 100; d = d * 100; cout << f << endl; cout << d << endl; return 0; }donne bien le résultat attendu :[^] # Re: Java et les double
Posté par mickabouille . Évalué à 1.
# Re: Java et les double
Posté par Docteur_Canard . Évalué à 2.
float nb = 9.37f;
nb = nb * 100;
---> nb = 937.0
# Re: Java et les double
Posté par jemore . Évalué à 4.
[^] # Re: Java et les double
Posté par jde . Évalué à 4.
...
double nb = 9.37;
System.out.println(nb);
nb = nb * 100;
DecimalFormat decimalFormat = new DecimalFormat();
System.out.println(decimalFormat.format(nb));
...
9.37
937
# Re: Java et les double
Posté par Pat Le Nain . Évalué à 4.
BigDecimal nb = new BigDecimal(9.37);
BigDecimal cent = new BigDecimal(100);
nb = nb.mutliply(cent);
-> nb.toString() donne 937.000
(BigDecimal accepte des double ou des String dans son contructeur)
# Re: Java et les double
Posté par Mr_max . Évalué à 7.
je m'explique :
x = 936.999999...9
10x = 9369.99999........
9x=8433
donc : x= 8433/9 = 937
Donc moi jvois pas ou est le probleme ;)
ok ok je sors ... => [ -]
[^] # Re: Java et les double
Posté par jde . Évalué à 1.
ça me rappelle la fac.
[^] # Re: Java et les double
Posté par kesako . Évalué à -1.
le coup du tres grand prof de math qui nous dit de faire le calcul en vitesse en considerant que pi vaut 3
:-)
[^] # Re: Java et les double
Posté par Nap . Évalué à 2.
[^] # Re: Java et les double
Posté par fmaz fmaz . Évalué à 2.
x=1 et y=0.99999999999999999999999999...
Si x!=y, alors x-y=e est strictement positif.
Il existe n tel que 10^{-n}<e.
Soit z=1-10^{-n}=0.9999999999999...99990000
y>z donc x-y<x-z or x-z=10^{-n}<e
donc e=x-y<e absurde donc x=y.
[^] # Re: Java et les double
Posté par dguihal . Évalué à 2.
Pt' 1 les maths en aa c'est pas facile
[^] # Re: Java et les double
Posté par Nap . Évalué à 1.
mais avec un nombre fini de 9 ça marche plus ton truc :o)
[^] # Re: Java et les double
Posté par calandoa . Évalué à 8.
attention! 936.999999.... = 937, mais 936.999999....9 != 937
Si si c'est pas pareil!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.