Discussion :

[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 ?

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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+

[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!

[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.

(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... c'est vrai... j'me suis endormi à la seconde page...

[bjb]

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

[Gfx]

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.