Un résulat inexact

Bonjour,

J'ai une erreur étrange en lançant ce programme dans lequel je saisis un montant HT : 100 , du taux de TVA : 20 et cherche le prix TTC.
Il devrait m'afficher 120 MAIS me donne 120,00001
Savez vous d'où peut venir cette inexactitude ?

Merci beaucoup d'avance pour l'aide que vous pourrez m'apporter.

voilà ce que j'ai fait en code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

import javax.swing.*; public class drty {   public static void main(String[] args) {   Float x,y; x=Float.parseFloat(JOptionPane.showInputDialog(null,"Entrez le montant hors taxe:" )); y=Float.parseFloat(JOptionPane.showInputDialog(null,"Entrez le taux de TVA:" )); JOptionPane.showMessageDialog(null,"Le montant TTC est : "+x*(1+y/100)); } }

---

DecimalFormat

http://docs.oracle.com/javase/7/docs...malFormat.html

Petit remarque préalable : utilise la balise code pour afficher du code.

Pour ton problème, c'est normal, cela est du à la représentation des float en mémoire (mantisse et exposant)

la précision des float est, me semble-t-il, de 6 chiffres significatifs, et de 15 chiffres significatifs pour les double.
Si tu souhaites ne plus avoir de type de problème, la classe BigDecimal peut t'aider.

Bonjour,


j'ai galéré avec les problèmes d'imprécisions sur les montants.
Personnellement, j'utilise maintenant des 'entiers' contenant le montant en centimes. Il n'y a plus d'imprécision dans les calculs.

Citation:

---

Envoyé par rtg57

j'ai galéré avec les problèmes d'imprécisions sur les montants.
Personnellement, j'utilise maintenant des 'entiers' contenant le montant en centimes. Il n'y a plus d'imprécision dans les calculs.

---

Ouaip.
Entiers, avec long ou BigInteger. Ou à la rigueur calculs exacts avec BigDecimal. Ça évite de devoir se demander si les imprécisions des flottants ne vont pas devenir significatives, quand on fait des calculs monétaires.
Les flottants c'est pas mal, par exemple pour des calculs de coordonnées ou de température, où on se tape que les calculs soient exacts, il faut juste qu'ils soient suffisamment précis.

+1 pour BigDecimal
voir : http://jmdoudoux.developpez.com/cours/developpons/java/

BigDecimal est la classe "approuvée" pour manipuler des montants monétaires

ça complique quand même pas mal l’exécution de calculs très simples, mais j étudie ça au plus vite.
merci pour vos réponses rapides.

Citation:

---

Envoyé par thierrys85

ça complique quand même pas mal l’exécution de calculs très simples,

---

Oui. Mais cela force à la rigueur. Les ordinateurs ne sont pas prévus, à l'origine pour faire des calculs de la manière dont un humain les pense. a + b pour un ordinateur ne veut pas dire a + b pour un humain. Et la plupart du temps c'est très bien comme ça, car on veut que l'ordinateur fasse comme un ordinateur, pas comme un humain.
Passer par des classes dédiées pour gérer l'addition permet de remettre les pendules à l'heure, au prix d'une écriture plus lourde.

Cela dit, il y a pas mal de langages où on utilise juste long et on ajoute la virgule à l'affichage. Au prix d'un risque accru de se tromper.

A noter que j'ai déjà vu au moins un article, lié au monde bancaire, où il était déterminé au final qu'utiliser des doubles, malgré l'erreur potentielle, coutait moins cher que les surcoût de dev pour faire ça de manière rigoureuse et repasser dans tous le code pour s'assurer du manque d'erreur. Il faut de toutes façon que tu arrondisse chaque opération car si tu vend un bic à 1.05€ HTVA, tu ne facture pas (à ma connaissance) 1.05€ *1.21(tva) = 1.2705€ mais 1.28€. A ce tarif, combien de bic faut-il vendre en une fois pour faire une erreur de 1 cent?

Avec des doubles, et en affichant tout à 2 décimales arrondies, faut déjà pas mal d'écritures comptables pour se gourer de 1 cents. Ou il faut acheter quelque millions d'action pour se retrouver à payer un euro de plus. Et franchement, celui qui achète un millions d'actions, cherche à faire des bénéfice largement supérieur à 1 euro :). Ce serait un peu comme payer 1 semaine de formation à 10 personnes du service de nettoyage pour doser correctement les produits afin d'économiser 300€/an. Le but est atteint mais est-il rentable? :)

C'est ce que je me suis toujours dit que les choses devraient être en pratique.

Mais on m'a toujours vendu qu'en comptabilité, on n'a pas le droit de "perdre" le moindre centime entré ou sorti, pour quelque raison que ce soit, erreur informatique ou autre. On doit toujours savoir où sont les centimes qui sont rentrés. Parfois, pour certaines étapes intermédiaires, on doit compter en dix-millièmes à la place.
Peu importe que ce ne soit pas beaucoup d'argent (en fait, carrément négligeable,) et que si quelqu'un se plaint on pourra toujours lui donner son centime en profits et pertes sans se demander où on l'a perdu. C'est interdit, et dans les contrôles comptables les amendes seront, elles, non négligeables si répétées.

C'est ce qu'on m'a dit, et n'ayant pas de formation comptable, j'ai cru les types dont c'est le boulot, en m'acquittant du mien qui est de leur fournir l'outil informatique faisant ce dont ils ont besoin.

c'est ce que j'ai cru aussi. Puis j'ai vu fonctionner des comptabilités :aie: