addition de Double

Version imprimable

15/12/2005, 14h56
badjojo

addition de Double

Bonjour,

Je m'adresse à la communauté car un problème m'empêche de dormir en ce moment... je n'arrive pas à comprendre.
Voici le bout de code fautif:

Double d1 = new Double(6.33);
Double d2 = new Double(6.33);
Double d3 = new Double(10);
double d4 = d3.doubleValue() + d1.doubleValue() + d2.doubleValue();
System.out.println("" +d4);

J'obtiens 22.65999999999999997 au lieu de 22.66 !!!!!!!!
Par contre si je fais:
double d4 = d1.doubleValue() + d2.doubleValue() + d3.doubleValue();
J'obtiens le bon résultat, 22.66 (j'ai d'abord ajouté le 10)

Après avoir fait différents tests et cherché, je ne trouve pas l'explication..

Alors je m'en remets à vos avis d'experts!!

Merci!
15/12/2005, 16h25
MangeurVasqué

Quel que soit le langage de programmation, les calculs en virgule flottante peuvent générer des erreurs d'arrondi. C'est inhérent à la représentation en mémoire des nombre réels.

A priori, dans le premier cas tu effectues (d3 + d2) + d1, qui génère une erreur d'arrondi. Ce n'est pas le cas pour ton second test, qui correspond à l'opération (d1 + d2) + d3.
15/12/2005, 17h25
badjojo

Merci pour ta réponse.
Ce qui me gêne néanmoins, c'est qu'un arrondi se produise sur un calcul aussi simple et avec des nombres aussi petit que 6.33 + 6.33 +10

Je savais qu'on pouvais obtenir des arrondis avec certains chiffres extremement grand, d'autres très petits, les casting double - float etc ...
Mais quand même, un double est sur 64 bits!!! et même si on tient compte de la représentation en virgule flottante, ça me surprend qu'on ait des arrondis sur des calculs avec des chiffres ni très petits, ni très grands, ni avec un grand nombre de chiffres après la virgule, et qui plus est avec un calcul censé donner un résultat avec 2 chiffres après la virgule (on n'est pas dans le cas de 1 / 3 = 0.3333333333333333333333333333 ....)

A mon avis, il ya une explication simple et rationnelle, mais laquelle?
15/12/2005, 20h39
fremsoi

J'suis curieux de comprendre aussi

Car si on fait
d1 + d2 ==> 12.6 ( et pas 12.6666666669..)
d3 + d2 ==> 16.3 ( et pas 16.2222222229..)
d3 + d1 pareil

Donc là je piges et rente qd même bleuffer
15/12/2005, 21h02
pk960

Citation:

Envoyé par badjojo

A mon avis, il ya une explication simple et rationnelle, mais laquelle?

Un double Java suit la norme IEEE-754 où un nombre à virgule flottante est représenté avec une mantisse sur une cinquantaine de bits et un exposant représentant une puissance de 2 sur une dizaine de bits.

Des valeurs comme 1, 1.5, 1.125 ou 633 sont représentées sans aucune perte de précision car elles peuvent être écrites sous la forme de 1*(2**0), 3*(2**-1), 9*(2**-3), 633*(2**0).

Par contre, une valeur comme 6.33 subit une erreur d'arrondi due au fait qu'il n'y a aucune façon de l'écrire exactement sous la forme de "mantisse * (2 puissance exposant)".
15/12/2005, 23h57
fremsoi

Ok mais pourquoi alors
6.33 + 6.33 donne 12.66 ( donc pas d'erreur d'arrondi )
et 10 + 6.33 + 6.33 provoque une erreur ( alors que 10 pose pas de problème )
16/12/2005, 10h07
MangeurVasqué

parce que quand tu évalues 10 + 6.33 + 6.33, le programme effectue en réalité

Code:

10 + 6.33 + 6.33 = 16.33 + 6.33

ce qui est différent de

Code:

6.33 + 6.33 + 10 = 12.66 + 10

Chaque étape intermédiaire est suceptible de générer une erreur d'arrondi différente. Tu ne remarques l'erreur d'arrondi globale que quand la cumulation des erreurs intermédiaires dépasse un certain seuil.
16/12/2005, 10h23
jcodeunpeu

salut,
étonnant en effet, mais j'ai du mal à croire qu'il n'y a pas solution .... :?:
16/12/2005, 10h31
bouye

Tu peux utiliser BigDecimal à la place mais ca n'enlève pas le problème, ca ne fait que le cacher/retarder en augmentant encore plus la précision.

Egalement, s'il s'agit juste de problème d'affichage (et non de problème de précision des calculs, comme dans une simulation scientifique) ; ce genre de chose peut vite être "effacée" en utilisant un NumberFormat ou un DecimalFormat correctement configuré.

Ce problème de précision apparait aussi dans les simul de population de poissons des scientifiques pour lesquels je bosse (mais sur des nombres beaucoup plus grand). Il est courrament admis qu'en général les erreurs de precision se contre-balancent les unes les autres d'elle même lors de (très) long calculs. Ce qui fait que le résultat est tout de même relativement précis et corrects.
16/12/2005, 11h35
badjojo

Merci pour vos lumières.. on avance un peu, même si on n'a toujours pas la réponse...

En effet, comment est-il possible que pour des nombres si banals, et des calculs si simples il puisse y avoir erreur d'arrondi.

Il s'agit d'un calcul extrêmement simple, qui devrait pouvoir être réalisé correctement avec des Floats, des Doubles, des BigDecimaux...
On est presque au niveau d'un " 1 + 1 = 2". Imaginez si une erreur pouvait se produire sur ce calcul.. quelle serait la fiabilité des logiciels en circulation???!!!

Je pense qu'il doit exister une faille dans ma façon de calculer avec les double ou qqe chose comme ça... sinon, ça serait grave.

Je travaille sur une application de gestion, ou des montants sont calculés au centime près.. juridiquement et fiscalement, il est important que les montants soient justes. alors si 10 + 6.33 + 6.33 donne autre chose que 22.66, je ne suis pas sorti de l'auberge!!!! :cry:
16/12/2005, 11h49
jowo

Si effectivement tes calculs sont dans le domaine de la gestion, je te conseille d'éviter les floats ou les doubles.

Prends-toi quelques heures à te documenter sur les problèmes d'arrondi, sur la classe BigDecimal ou peut être il existe des classes spécifiques aux calculs financiers.

Je pense que tu amortiras rapidement ces heures.

Un lien intéressant. Il en existe des centaines sur ce sujet. :google: est ton ami.

'jour,
je trouve ce sujet assez intéressant. Surtout que si on fait qques tests, on se rend compte que l'ordre n'est pas le seul facteur qui influence le résultat :

Code:

1
2
3
4
5
6
7
8
9
10
a = 1.33 b = 1.33 c = 1.0 Sum (a+b+c)= 3.66 Sum (c+a+b)= 3.66
 a = 2.33 b = 2.33 c = 2.0 Sum (a+b+c)= 6.66 Sum (c+a+b)= 6.66
 a = 3.33 b = 3.33 c = 3.0 Sum (a+b+c)= 9.66 Sum (c+a+b)= 9.66
 a = 4.33 b = 4.33 c = 4.0 Sum (a+b+c)= 12.66 Sum (c+a+b)= 12.66
 a = 5.33 b = 5.33 c = 5.0 Sum (a+b+c)= 15.66 Sum (c+a+b)= 15.66
 a = 6.33 b = 6.33 c = 6.0 Sum (a+b+c)= 18.66 Sum (c+a+b)= 18.66
 a = 7.33 b = 7.33 c = 7.0 Sum (a+b+c)= 21.66 Sum (c+a+b)= 21.66
 a = 8.33 b = 8.33 c = 8.0 Sum (a+b+c)= 24.66 Sum (c+a+b)= 24.659999999999997
 a = 9.33 b = 9.33 c = 9.0 Sum (a+b+c)= 27.66 Sum (c+a+b)= 27.659999999999997
 a = 10.33 b = 10.33 c = 10.0 Sum (a+b+c)= 30.66 Sum (c+a+b)= 30.659999999999997

Je serais curieux d'avoir l'explication exact du phénomène... :D

Citation:
Envoyé par vincent63
'jour,
je trouve ce sujet assez intéressant. Surtout que si on fait qques tests, on se rend compte que l'ordre n'est pas le seul facteur qui influence le résultat :
Code:

1 2 3 4 5 6 7 8 9 10 a = 1.33 b = 1.33 c = 1.0 Sum (a+b+c)= 3.66 Sum (c+a+b)= 3.66 a = 2.33 b = 2.33 c = 2.0 Sum (a+b+c)= 6.66 Sum (c+a+b)= 6.66 a = 3.33 b = 3.33 c = 3.0 Sum (a+b+c)= 9.66 Sum (c+a+b)= 9.66 a = 4.33 b = 4.33 c = 4.0 Sum (a+b+c)= 12.66 Sum (c+a+b)= 12.66 a = 5.33 b = 5.33 c = 5.0 Sum (a+b+c)= 15.66 Sum (c+a+b)= 15.66 a = 6.33 b = 6.33 c = 6.0 Sum (a+b+c)= 18.66 Sum (c+a+b)= 18.66 a = 7.33 b = 7.33 c = 7.0 Sum (a+b+c)= 21.66 Sum (c+a+b)= 21.66 a = 8.33 b = 8.33 c = 8.0 Sum (a+b+c)= 24.66 Sum (c+a+b)= 24.659999999999997 a = 9.33 b = 9.33 c = 9.0 Sum (a+b+c)= 27.66 Sum (c+a+b)= 27.659999999999997 a = 10.33 b = 10.33 c = 10.0 Sum (a+b+c)= 30.66 Sum (c+a+b)= 30.659999999999997
Je serais curieux d'avoir l'explication exact du phénomène... :D
Essaie d'effectuer ces calculs avec la même représentation qu'un ordinateur et tu seras surpris que tu arriveras au même résultats affichés. :wink:

Je suis étonné du résultat:

Code:

1
2
3
4
5
		float sumFloat = 8.0f + 8.33f + 8.33f;
        double sumDouble = 8.0d + 8.33d + 8.33d;
 
        System.out.println("Float:  " + sumFloat);
        System.out.println("Double: " + sumDouble);

Résultat:

Code:

1
2
3
 
Float:  24.66
Double: 24.65999984741211

16/12/2005, 12h21
FFF

Re: [addition de Double] Enigme !!

Citation:

Envoyé par badjojo

Bonjour,

Je m'adresse à la communauté car un problème m'empêche de dormir en ce moment... je n'arrive pas à comprendre.
Voici le bout de code fautif:

Double d1 = new Double(6.33);
Double d2 = new Double(6.33);
Double d3 = new Double(10);
double d4 = d3.doubleValue() + d1.doubleValue() + d2.doubleValue();
System.out.println("" +d4);

J'obtiens 22.65999999999999997 au lieu de 22.66 !!!!!!!!
Par contre si je fais:
double d4 = d1.doubleValue() + d2.doubleValue() + d3.doubleValue();
J'obtiens le bon résultat, 22.66 (j'ai d'abord ajouté le 10)

Après avoir fait différents tests et cherché, je ne trouve pas l'explication..

Alors je m'en remets à vos avis d'experts!!

Merci!

tu as essayé avec du transtypage :
d4=(double)d1+(double)d2+... ?

ou tout simplement :
d4=d1+d2+d3

puisque tes données sont de même type

cette erreur provient en général d'une imprecision due à la conversion float -> double ou double -> double

pour éviter ces problèmes il faut éviter au maximum de passer d'un type de données à un autre même si ce type reste le même !
Un post a été résolu sur un sujet similaire concernant le PHP...

++
16/12/2005, 12h30
vincent63

Bon, voilà un bout de réponse...

http://cch.loria.fr/documentation/IEEE754/ACM/goldberg.pdf

oui, cependant je remarque que
Code:

1 2 3 4 5 6 7 float sumFloat = 8.0f + 8.33f + 8.33f; double sumDouble = 8.0d + 8.33d + 8.33d; double sumDouble2 = 8.33d + 8.33d + 8.0d; System.out.println("Float: " + sumFloat); System.out.println("Double: " + sumDouble); System.out.println("Double2: " + sumDouble2);
donne toujours
Code:

1 2 3 4 Float: 24.6 Double: 24.659999999999997 Double2: 24.66
d'ailleurs, pourquoi une cette différence avec le résultat précedent de
Double: 24.65999984741211 entre deux ordinateurs ????
doit on en conclure que les float sont plus appropriés ici ... :?:

16/12/2005, 13h07
vincent63

J'suis pas sûr que l'on puisse dire que les float soient plus appropriés.

Entre 24.66 et 24.6, il y a une différence de 0.06

Pour les double, la différence est moins grande.
16/12/2005, 13h11
FFF

pas facile...
j'ai déjà eu moi aussi des soucis de ce type pour des calculs scientifiques. et j'en ai retenu que pour avoir des calculs numériques précis, il fallait être très rigoureux dans l'écriture des doubles (même les chiffres doivent être écrits avec précision) sinon l'ordi te mets ce qu'il veut là où il y a des manques.
Manipuler des doubles c'est chaud !!!
Plein de scientifiques ont écrit des doc sur le calcul numérique, il faut faire une recherche la dessus sur google.
16/12/2005, 13h13
jcodeunpeu

oui, :oops: bien sur, en plus j'ai vu ton post avec le lien qu'aprés avoir envoyé le mien. la réponse me parait bien être dans ce pdf, quand au fait que 2 ordinateurs n'obtiennent pas le même résultat sur l'opération (cf.FFF),
que dire ?
17/12/2005, 06h29
bouye

Les architectures des machines ne sont pas les mêmes (indépendement de la norme IEEE et de la précision utilisée pour les nombres flottants), leur unités de calculs sont implémentées de manières différentes (avec des bugs différents...) et suivant les languages et les compilateurs des optimisation sont + ou - utilisées pour simplifier/accélérer le calcul (et cela peut impliquer parfois des transtypages et des cast non-explicites dans le code).

As-tu également essayer d'inclure l'instruction strictfp dans la classe où tu fais ton calcul ?
17/12/2005, 14h27
jcodeunpeu
merci bouye,
on ne le dis jamais assez, l'utilisation des parenthèses a du bon même quand on les croit inutiles :
Code:

1 2 3 double sumDouble = 8.0d + (8.33d+ 8.33d); double sumDouble2 = 8.33d + 8.33d + 8.0d;
donne bien un unique résultat : 24.66
pour les architectures, oui aussi, car je ne parviens pas à obtenir le même résultat que jowo sur sumDouble ...
et merci pour le lien, le faq sur l'ellipse m'est particulièrement util...
A+
21/12/2005, 17h12
badjojo

Je ne comprends pas très bien ta remarque, jcodeunpeu :

Mathématiquement, ( a + b ) +c = a + ( b + c) non???

Donc, même si du fait de la représentation machine, la place des parenthèses a une répercussion sur le résultat final, je ne vois pas quelle logique pourrait indiquer où placer lesdites parenthèses dans le cas présent...

En tout cas, ayant initié la question, je remercie tout ceux qui ont participé à la discussion, et conclut la chose suivante:

- tout le monde est d'accord avec le fait que le problème vient de la représentation mémoire des nombres, et des calculs bas niveau.

- qqes personnes ont trouvé des documentations d'une centaine de pages, sûrement très intéressantes mais trop complexes pour le commun des mortels (je pense d'ailleurs que les personnes qui on fourni ces docs ne les ont pas lues: si elles l'avaient fait, elles auraient pû précisemment expliquer le phénomène en se basant sur la représentation machine dans le cas précis qui nous intéresse..)

J'en conclus que le problème est trop complexe pour le développeur moyen...

En tout cas merci pour vos efforts!
21/12/2005, 18h15
vincent63

'soir,
Hop, me revoilà... pour la réponse à cette question, voir :

http://www.developpez.net/forums/vie...32680&start=15

où l'on a aussi débattu sur le sujet.

Citation:

(je pense d'ailleurs que les personnes qui on fourni ces docs ne les ont pas lues:

Si c'est de moi qu'on parle... ben euh... :oops: c'est vrai... j'me suis endormi à la seconde page... :D
27/01/2006, 20h44
bjb

Nombre décimal != Nombre à virgule flotante

Bonjour à tous,

Pour résumer la situation le comportement que vous avez découvert n'est pas surprenant, vous aurez le même quelque soit le langage utilisé (à condition que le compilateur utilise vraiment les nombre à virgule flotante, désasembler pour en avoir le coeur net).

En informatique on sépare deux catégories de nombre décimaux :
- les nombres à virgule flotante : pratique, rapide (souvent utilisant les capacité d'un coprocesseur avec des instructions spécifiques)
- les nombres décimaux "traditionels" : complexe & lent (car peu ou pas accéléré dans le matériel, sauf instructions additionelles)

Les nombres à virgule flotante sont parfait pour : les calculs scientifiques (mesures d'élément réel, statistiques, 3D ...) car sauf besoin de précision absolu, la légère différence de valeur constatée n'aura aucune différence sur l'exactitude (signification) des résultats.

En Java suivant si l'on à besoin de plus ou moins de précision, on choisira un type float (simple précision) ou un double (double précision) qui sont tout deux des types simples. Si l'on désire que le comportement des calculs flotant soit strictement compatible avec la norme IEEE, on peut utiliser le modificateur strictfp. Ceci sera peut-être un peu plus lent (optimisation moins agréssible de la VM), mais assurera une totale portabilité entre VM/microprocesseur.

Par contre ces nombre à virgules ne doivent JAMAIS être utilisés en comptabilité car c'est une matière où les calculs doivent être exacts et suivre des règles d'arrondi stricts. A cet effet, il existe un type BigDecimal (un type complexe), qui permet de faire tous les calculs dont on a besoin tout en maitrisant intégralement le niveau de précision, d'arrondi, etc.
Un peu de lecture avec des exemples de calculs de compta :
http://javapronews.com/javapronews-47-20050509HowtheBigDecimalClassHelpsJavagetitsArithmeticRight.html

Il en va de même pour tout calcul nécessitant coute que coute une exactitude absolue.

Voilà, maintenant plus besoin de vous prendre la tête.

A noter que cette différence existe à ma connaissance dans bon nombre de langage Java/C/C++/C#/Pascal ... (sauf encore une fois, directive particuliere de compilation surchargeant le comportement habituel) tout simplement car c'est une contrainte matérielle ;-)

Un petit article dans une FAQ avec un lien sur tout celà serrait pas mal ..

A+
JB
27/01/2006, 23h29
Gfx

Citation:

J'en conclus que le problème est trop complexe pour le développeur moyen...

Et j'en conclue que le developpeur moyen devrait apprendre comment fonctionne un ordinateur :(

Une solution pour certains calculs qui doivent etre effectues sans perte de precision est d'utiliser une virgule fixe et des entiers ou des longs.