Version imprimable
Voici un bout de code tout simple :
J'obtiens le résultat suivant : 21296.194499999998 au lieu de 21296.1945.Code:
2
3
4
5
Quelqu'un aurait-il une solution pour résoudre ce problème sans passer par les BigDecimal et sans utiliser une précision qui pourrait introduire une erreur dans mes calculs?
C'est la précision éternelle de java....
Je pense que tu peux regarder dans le package java.math (que je n'ai jamais essayé).
Il y a les classes BigInteger et BigDecimal.
Dans BigDecimal tu as une méthode multiply.
Code:
2
3
4
5
6
7
8
9
10
11
12
Sinon, tu peux toujours passer par une méthode d'arrondi à x chiffres aprés la virgule.
Ou encore, ne faire que des multiplications sur des entiers. C'est plus sur
Dans ton cas, tu multiplie tout par 1000 et tu redivises le résultat par 1000 à la fin ...
Ce sujet a déjà été traité cette semaine (addition de double)
J'ai cherché sur le forum avant de poster mon message, mais j'ai cherché à "multiplication double" et pas à "addition double"...
Pour les BigDecimal, ça marche pas non plus car j'obtiens :
21296.19449999999801450734082663988613836786099092128303478244077950876089744269847869873046875
donc c'est toujours pas ce que je veux...
Quand à arrondir la valeur, ça me fait perdre de la précision, parce que dans cet exemple, je peux arrondir à 4 chiffres après la virgule, mais dans un autre cas ça peut être 5 ou 6 (voir plus) chiffres après la virgule...
Bon en tout cas merci pour vos réponses. :D
Ca depend de quoi ton nombre de chiffres aprés la virgule ?
le nombre de chiffres après la virgule ne dépend pas de moi, ça s'est sur :(
Ce sont des données extraites d'un fichier xml (que l'on me fournit...).
Pour en revenir au sujet déjà traité cette semaine, je tiens quand même à préciser qu'aucune solution n'a été trouvée, donc le sujet reste ouvert...
Tu peux assez facilement retrouver le nombre de chiffres après la virgule pour un double donnée. Tu convertie en String et tu comptes le nombre de caractères de la virgule (ou du point) jusqu'à la fin.
Après, tu peux tout multiplier par 10 x le nombre de chiffres après la virgule,
faire la multiplication des 2 entiers (des long) et rediviser par 10 x le nombre de chiffres après la virgule
Ca reste une solution possible et sûr
MOI, j'obtiens 21296.1945 en utilisant correctement la classe BigDecimal.Citation:
Envoyé par xso
Code:
2
3
4
5BigDecimal monBigDecimal1 = new BigDecimal(0.815d); BigDecimal monBigDecimal2 = new BigDecimal(26130.3d); BigDecimal monBigDecimal3 = monBigDecimal1.multiply(monBigDecimal2); System.out.println(monBigDecimal3.setScale(4, BigDecimal.ROUND_CEILING));
Bé tu fais un arrondi à la quatrième décimale :
Ducoup je vois pas l'interêt de passer par des BigDecimal...Code:
2System.out.println(monBigDecimal3.setScale(4, BigDecimal.ROUND_CEILING));
:?:
Pour ce qui est de la solution de compter le nombre de décimal en passant par des String, j'ai peur de perdre énormént de perfomance sur mon appli parce que j'ai pas qu'une seule valeur à analyser, non?
De toute façon, tu devras arrondir pour afficher ton nombre.
Je peux me tromper mais un nombre avec 30 décimals, ça n'a pas de sens physique. Tout instrument a une certaine précision...
En effet, je vais me résoudre à arrondir mes résultats à la douzième décimale...
Mais je trouve quand même étrange que Java ne permette pas de faire un calcul aussi simple que 0.815 * 26130.3 sans se tromper...
Merci Jowo et Sebounet19 pour votre aide :merci: et votre patience ;-)
Java n'est pas vraiment fait pour le calcul, je pense que tu peux ajouter des librairies spécialisées qui te rendent un meilleur résultat.
c'est pas une question de qualité de calcul c'est une question de gestion mémoire.
La JVM alloue 64 bits pour un double...Il faut bien les remplir.
Passes par un float qui lui est codé sur 32 bits.
Tu auras une précision plus grossière.
Tchou !
'soir,
En fait, aucune solution n'a été trouvé parce qu'il n'en existe pas.Citation:
Pour en revenir au sujet déjà traité cette semaine, je tiens quand même à préciser qu'aucune solution n'a été trouvée, donc le sujet reste ouvert...
A priori, il n'est pas possible de représenter certaines valeurs décimales avec des types primitifs (double, float, etc...) sans avoir recours à une approximation.
Du coup, lors de certains calculs, les résultats peuvent être mathématiquement faux et être pourtant ce qu'il y a de plus proche avec une représentation informatique.
De la même manière, (cf. un expert Java de ma boite), la valeur affichée par un System.out ne correspond pas toujours à la valeur exact retenue en mémoire. Par exemple :
Voir : http://java.sun.com/j2se/1.4.2/docs/api/Citation:
BigDecimal
public BigDecimal(double val)
Translates a double into a BigDecimal. The scale of the BigDecimal is the smallest value such that (10scale * val) is an integer.
Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances notwithstanding.
The (String) constructor, on the other hand, is perfectly predictable: new BigDecimal(".1") is exactly equal to .1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one.
Parameters:
val - double value to be converted to BigDecimal.
Throws:
NumberFormatException - val if val is infinite or NaN.
Voilà tout... :D
Je soupconne un probleme equivalent en C, C++, Pascal, ... et n'importe quel language qui utilise la norme IEEE ou equivalent pour la representation et les calculs sur nombres flottants (l'assembleur egalement alors ?).Code:Java n'est pas vraiment fait pour le calcul, je pense que tu peux ajouter des librairies spécialisées qui te rendent un meilleur résultat.
Mais de la a tous se mettre a programmer en FORTRAN, en Scheme/LISP ou en ML.........................
Sinon il faut trouver (ou se faire) une librairie numerique specialisee. Mais la on peut alors perdre en performances et en general ca coute cher.
d'accord avec bouye !
D'une façon générale si tu n'obtiens pas le résultat attendu par ton ordi ben c que tu lui dis pas de faire les choses correctement (et c pas facile) !
La manipulation des doubles (cf le poste sur l'addition de double) est très délicate, on utilises cette précision pour des calculs scientifiques (pas pour aditionner des sous ou des carottes !)
Un nombre double ne s'écrit pas n'importe comment non plus, par exemple en info il se peut très bien que ces deux doubles ne soient pas égaux :
d1=8.1
d2=8.1000
Bref en gros si tu n'as pas à déterminer l'âge de l'univers ou résoudre l'équation de schrödinger (donc t'as pas besoin d'être très précis) n'utilise pas les double (en plus ton appli ira sûrement plus vite !) !
Si par contre tu dois résoudre une équation par différences finies en mode implicite allant au 5ème ordre, bon là tu peux envisager les doubles et un conseil avant d'écrire koi que ce soit c'est de lire des bouquins sur "les méthodes numériques" ou informatique numérique...
Oulala... Fouilhouilhou...Citation:
La manipulation des doubles (cf le poste sur l'addition de double) est très délicate, on utilises cette précision pour des calculs scientifiques (pas pour aditionner des sous ou des carottes !) ....
Bref en gros si tu n'as pas à déterminer l'âge de l'univers ou résoudre l'équation de schrödinger (donc t'as pas besoin d'être très précis) n'utilise pas les double (en plus ton appli ira sûrement plus vite !) !
Mais pas du tout!!! :D
Les deux postes sur les doubles montrent justement les limites de ce type primitif. Ils ne permettent pas de représenter PRECISEMENT certaines valeurs. Donc pas question de les utiliser dans des calculs nécessitant une extrême précision.
ben ils servent à quoi alors ?? C'est bien avec ceux ci que tu peux avoir des 10E-350 ou 10E+241... non pour toi c'est pas assez précis ?? Un double ça s'écrit de façon précise dans un programme : 1.200000000000000 s'il le faut.Citation:
Envoyé par vincent63
Je te renvoie à la page précédente et sur le lien vers la java doc. Toutes les valeurs ne peuvent pas être représentées EXACTEMENT avec les doubles. Par exemple, 0,1 n'a pas de représentation PRECISE avec ce type primitif.Citation:
ben ils servent à quoi alors ?? C'est bien avec ceux ci que tu peux avoir des 10E-350 ou 10E+241... non pour toi c'est pas assez précis ?? Un double ça s'écrit de façon précise dans un programme : 1.200000000000000 s'il le faut.
Pour des calculs qui demandent une grande précision, un léger décalage multiplié plusieurs fois peut donner des valeurs fausses.
Voici une 'tite méthode qui fonctionne à merveille pour faire des arrondis
Code:
2
3
4
5
6
7
8
9
je me répète, mais si 1.2 n'a pas de représentation précise en double alors ça sert à quoi ?? sinon je suis d'accord qu'une légère imprcision de la représenatation d'un nombre cause des erreurs.
Disons que si tu calcules 10 + 6,33 + 6,33 euros tu obtiendras 22.65999999999999999999999 je crois (en double). Comme en euros, seules les deux premières valeurs après la virgule t'intéressent, tu arrondis et hop, le résultats est bon.
Les doubles permettent d'avoir des valeurs très très proches des "vraies" dans un ensemble de définition immense. Dans la plupart des cas (99%), c'est largement suffisant. Mais si tu dois travailler sur des valeurs décimal exactes qui ne souffrent d'aucune erreur de calcul (ie. si tu veux obtenir 22.66 exactement dans le calcul précédent), alors il faut utiliser autre chose.
moi je savais pas qu'on programmait des ordi pour donner de mauvais résultats !!! :lol: Non c'est pas sérieux je pense
1+1=2 même avec des doubles, simplement si tu obtiens 1.99999999999999999 c'est parce que tu n'as pas rentré en machine 1+1 c'est tout mais plutôt 1.0000000000000000000000001+0.999999999999999999999998=1.999999999999999999999999999
après faut comprendre pourquoi ton 1 devient 1.00000000000000000001 pour éviter ce problème.
Bon je dis ça mais j'y connais juste un tout petit peu dans ce domaine ! Mais ça me paraît un peu faux ce que tu dis ! je trouve pas grand chose sur google sur le type double....
Moi je pense que vu que les doubles sont sur 64 bits, je pense que le fait d'écrire à la main dans ton programme le chiffre 2 ou 1 ou 1.2 , ça ne suffit pas, il faut l'écrire peut être sous forme d'un tableau de 64 bits ! pour avoir un vrai 2,0000000000000000 ou 1.00000000000000
Ca serait à essayer de d'abord écrire ses nombres en binaires 64 bits et ensuite de les convertir en double, c'est peut être la clef du problème !
Je sais qu'à un certain niveau mathématico-informatique, les calculs se font par l'intermédiaire des opérateurs de bits et non des opérateurs usuels... (gain de temps de précision...)
Voilà des pistes à creuser...
d'ailleurs il serait bien d'ajouter aux forums de developpez.com un thread concernant les calculs numériques / méthodes numériques / calculs scientifiques
Moi??? Mais j'ai rien dit.... :DCitation:
Mais ça me paraît un peu faux ce que tu dis !
http://java.sun.com/j2se/1.4.2/docs/api/index.html
Citation:
Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances notwithstanding.
(euh, bon, c'est une traduction Google, mais on comprend l'idée)Citation:
Note: les résultats de ce constructeur peuvent être quelque peu imprévisibles. L'on a pourrait supposer qui nouveau BigDecimal(.1) est exactement égal au .1, mais elle est réellement égale au .1000000000000000055511151231257827021181583404541015625. C'est ainsi parce que le .1 ne peut pas être représenté exactement comme double (ou, pour cette matière, comme fraction binaire de toute longueur finie). Ainsi, la longue valeur qui est passée dedans au constructeur n'est pas exactement égale au .1, malgré aspects.
J'ai le même genre de problème avec les float ??
s7=s7+(float)8.9;
jLabel13.setText(String.valueOf(s7));
s7 est au départ à 0. Voici ce que ce calcul donne déjà aprés 3 calculs... :?
1 - 8.9
2 - 17.8
3 - 26.6999999
Ben tu relis tout le sujet lol :)
Merci, la fonction postée ci dessus marche nickel pour moi (je suis passé en double...)
essayer *= en opérateur.