Précision de calcul

Une petite question sur la précision de calcul,

j'ai trouvé pas mal de messages sur le forum qui parlent de ce problème mais pas de réponse que je comprenne vraiment.
Voilà un exemple tout simple que je ne comprend pas :

Code:

---

1 2 3 4

double a = 230.13075; double b = 178.17765;   double result = a - b;

---

Dans ce cas result vaut 51.953100000000006
Je ne sais pas trop comment corriger le problème ... pour un calcul aussi simple !

Et avec des float c'est pire :

Code:

---

1 2 3 4

float a = 230.13075f; float b = 178.17765f;   float result = a - b;

---

Result vaut 51.95311 au lieu de 51.9531

Est-ce que quelqu'un à une méthode claire pour avoir un calcul exact ?

C'est un problème de représentation interne propre au système, pas au langage.
Tu as essayé avec java.math.BigDecimal ? Il me semble que ça résout le problème (pas le temps de vérifier...)

Merci mais ...
J'avais aussi essayé BigDecimal et ça ne semble pas résoudre le problème :

Code:

---

1 2 3 4

BigDecimal a = new BigDecimal(230.13075); BigDecimal b = new BigDecimal(178.17765);   double result = a.subtract(b, MathContext.UNLIMITED).doubleValue();

---

result vaut alors 51.953100000000006 :(

Si tu veux garder la precision des BigDecimal, reste en bigdecimal et ne les transforme pas en double. Vue que les doubles ne te garantissent pas la precision que tu souhaites:

Exemple :
MathContext mContext=new MathContext(10);

BigDecimal bdA= new BigDecimal(a,mContext);
BigDecimal bdB=new BigDecimal(b,mContext);
BigDecimal res=bdA.subtract(bdB,mContext);

System.out.println("res :"+res);

David Gimelle
Developpeur J2EE
http://getj2ee.over-blog.com

Gio,

En repassant en double, tu recrées le problème : le nombre de valeurs exactement représentables avec des flottants à taille fixe est très petit par rapport à la dynamique possible (c'est à dire par rapport aux valeurs acceptées par les variables de ce type).
Il est donc rarissime de tomber sur une de ces valeurs.

Un test plus complet :

Code:

---

1 2 3 4 5 6 7 8 9

BigDecimal a = new BigDecimal(230.13075); BigDecimal b = new BigDecimal(178.17765); double test2 = 51.9531; BigDecimal test3 = new BigDecimal(51.9531);   double result1 = a.subtract(b, MathContext.UNLIMITED).doubleValue(); double result2 = test2; double result3 = test3.doubleValue();

---

result1 = 51.953100000000006
result2 = 51.9531 // donc un double peut sans problème prendre cette valeur
result3 = 51.9531 // donc il semble que la conversion en double n'affecte pas la valeur

Citation:

---

En repassant en double, tu recrées le problème

---

Je ne comprends pas pourquoi (cf test3 et result3 ci-dessus)

Citation:

---

Si tu veux garder la precision des BigDecimal, reste en bigdecimal et ne les transforme pas en double. Vue que les doubles ne te garantissent pas la precision que tu souhaites

---

Mais pourtant les doubles (et même les floats il me semble) peuvent sans problème contenir le résultat (cf test2 et test3 ci-dessus).
En fait je voudrais juste faire une fonction qui revoie un double avec la bonne valeur (i.e. la variable result2 ou result3 ci-dessus)

Ce bout de code devrais resoudre ton probleme :

// Fixe le scale a 10 digit
MathContext mContext=new MathContext(10);

// calcule avec 10 digit
BigDecimal bdA= new BigDecimal(a,mContext);
BigDecimal bdB=new BigDecimal(b,mContext);
BigDecimal res=bdA.subtract(bdB,mContext);
System.out.println("res :"+res);

// une fois le calcule termine tu peux le transformer en double
double d = res.doubleValue();
System.out.println("d:"+d);

Salut,


Comme cela a été dit, les float/double ont une imprécision plus ou moins grande qui peut fausser les résultats. Or comme tu utilises des doubles pour initialiser tes BigDecimal tu conserves cette "imprécision" !

La preuve :

Code:

---

1 2 3 4 5

BigDecimal a = new BigDecimal(230.13075); BigDecimal b = new BigDecimal(178.17765);   System.out.println(a); System.out.println(b);

---

Le code ci dessus t'affiche ceci :

Code:

---

1 2	230.130750000000006139089236967265605926513671875 178.177649999999999863575794734060764312744140625

---

:arrow: Il s'agit de l'approximation représentant les doubles 230.13075 et 178.17765, et lorsque tu fait la soustraction des deux tu obtiens 51.953100000000006275513442233204841613769531250...



Donc tu as deux solutions :

• Soit tu as besoin de calcul super-précis, et tu utilises la classe BigDecimal mais en aucun cas des floats ou des doubles qu'il te faut bannir !
• Soit tu peux de contenter d'une précision moindre, ce qui est le cas dans la plupart des applications, et tu formates les float/double afin de n'afficher qu'une nombre limité de décimales afin de te préserver des erreurs d'approximations.

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

double a = 230.13075; double b = 178.17765; double c = a - b;   // Affichage par défaut (avec les approximations) : System.out.println(a); System.out.println(b); System.out.println(c);   System.out.println();   // On utilise un formatter avec un maximum de 8 décimales : NumberFormat nf = NumberFormat.getNumberInstance(Locale.US); nf.setMaximumFractionDigits(8);   // Affichage OK (sans les approximations) : System.out.println( nf.format(a) ); System.out.println( nf.format(b) ); System.out.println( nf.format(c) );

---

Ce qui donne :

Code:

---

1 2 3 4 5 6 7

230.13075 178.17765 51.953100000000006   230.13075 178.17765 51.9531

---

a++

Citation:

---

Envoyé par David Gimelle

Ce bout de code devrais resoudre ton probleme :

// Fixe le scale a 10 digit
MathContext mContext=new MathContext(10);
...

---

Effectivement celà résoud bien le problème de cet exemple mais la précision à 10 digits me semble arbitraire et pourrait ne pas fonctionner pour d'autres exemples.
Et si j'ai bien compris celà revient a faire un calcul avec des doubles et arrondir le résultat à 10 digits. C'est ça ?

Citation:

---

Envoyé par adiGuba

BigDecimal a = new BigDecimal(230.13075);

System.out.println(a); // 230.130750000000006139089236967265605926513671875

---

Justement je ne comprend pas du tout ce fonctionnement :

Code:

---

1 2 3 4 5

double da = 230.13075; BigDecimal a = new BigDecimal(da, MathContext.UNLIMITED);   System.out.println(da); // 230.13075 System.out.println(a); // 230.130750000000006139089236967265605926513671875

---

Du coup je ne comprend pas à quoi sert ce MathContext.UNLIMITED puisque il semble que la valeur du double (da) soit la bonne et pourtant la conversion en BigDecimal perd de la précision malgré le MathContext.UNLIMITED (alors qu'il me semble que la javadoc définie cette opération comme exacte : When a MathContext object is supplied with a precision setting of 0 (for example, MathContext.UNLIMITED), arithmetic operations are exact)

Oui le 10 digit est arbitraire.

Si tu initialise un BigDecimal avec un double tu vas enregistrer avec un "precision" un double qui a une valeur pas tres precise.

(Mais assez precise quand meme, car dans la vrai vie un resultat avec plus de 14 chiffres apres la virgule en général ca n'a pas bcp de sens.)

Ce bout de code devrais te donner une idee :

BigDecimal b1 = new BigDecimal(230.13075); // Initalise avec un double
BigDecimal b2 = new BigDecimal("230.13075");// avec un String
BigDecimal b3 = new BigDecimal(230.13075,new MathContext(10)); // avec un double sur 10 digit

System.out.println("b1:"+b1);
System.out.println("b2:"+b2);
System.out.println("b3:"+b3);

Resultat :
[testng] b1:230.130750000000006139089236967265605926513671875
[testng] b2:230.13075
[testng] b3:230.1307500

Salut,


Comme cela a été dit, les floaT/double ne sont pas précis.
En fait lorsque tu fais :

Code:

---

double da = 230.13075;

---

:arrow: da vaut en réalité 230.130750000000006139089236967265605926513671875

Et pour pallier à cette imprécision les doubles sont "tronqué" à l'affichage ce qui fait que tu as bien 230.13075...

Le problème vient du fait que les imprécisions peuvent se cumuler pendant les calculs et alourdir le problème au point d'être visible.


Donc encore une fois tu as deux solutions :

• Utiliser des BigDecimal initialisé avec des String ou des int/long et bannir les float/double, ceci afin d'éviter toutes imprécisions !
  
• Utiliser des float/double en tronquant le résultat afin de limiter les problèmes.

C'est comme ca !


a++