Operation sur Float

Bonjour,
Je fais une opération toute bête :

Code:

---

1 2 3 4 5

float montant_win = (float) 0.8; float montant_total = (float) 1.2; float montant_dernier = (float) 0.4; float montant = montant_win - (montant_total - montant_dernier); System.out.println(montant);

---

et voilà ce que j'obtiens (au lieu de 0) :
1.110223E-16

Quel est le probleme ??
Merci

Il n'y a pas de problème. Les nombres décimaux ne peuvent pas tous etre écrits sous forme de somme de puissances de 1/2, ce qui amène inévitablement des petites erreurs dans les virgules en fin de float lors des conversions décimal->binaire. Ton opération est donc, d'un point de vue mathématique:

Code:

---

1 2	0.8+-poussière - (1.2+-poussières - 0.4+-poussières) = +-3*poussières

---

De plus comme l'a dit tchize, c'est du à la représentation des nombres flottants, cf le lien suivant :lien.


Au passage, en Java les constantes float sont suffixés par un F.

Code:

---

1 2 3 4

float montant_win = 0.8F; float montant_total = 1.2F; float montant_dernier = 0.4F;

---

Ca te permet d'éviter de caster quand tu déclare tes variables.


Si tu as besoin d'une plus grande précision, tu peux envisager de te tourner vers la classe BigDecimal.

Tu peux utiliser les double, c'est sur 8 octets, donc plus de précision, mais tu n'aura toujours pas le résultat exacte malheureusement pour ton cas.
a++

Ok merci, donc pour les monétaires par exemple, le mieux est de prendre bigdecimal ?

Citation:

---

Envoyé par Hesiode

Ok merci, donc pour les monétaires par exemple, le mieux est de prendre bigdecimal ?

---

Oui c'est une idée.

Mais en général, il est plus simple de créer une classe Money avec un ensemble de deux ints et tu recodes les opérations simplement pour ce que tu as besoin. BigDecimal peut être assez lourd parfois.

Citation:

---

Envoyé par Baptiste Wicht

Mais en général, il est plus simple de créer une classe Money avec un ensemble de deux ints et tu recodes les opérations simplement pour ce que tu as besoin. BigDecimal peut être assez lourd parfois.

---

tu penses à quoi plus spécifiquement?
quand on voit le nombre de choses à faire (décimales, arrondis, etc.) quel est le bon compromis : utiliser un bulldozer ou réinventer la brouette?

Citation:

---

Envoyé par professeur shadoko

tu penses à quoi plus spécifiquement?
quand on voit le nombre de choses à faire (décimales, arrondis, etc.) quel est le bon compromis : utiliser un bulldozer ou réinventer la brouette?

---

Par exemple, sur un projet au boulot, on utilisait une classe Money qui stockait tout dans un seul long en stockant directement les centimes. Comme ça, on a simplement une valeur, il suffit de la diviser par cent pour avoir les unités et de prendre les 2 derniers chiffres pour avoir les centimes.

Ca peut donner quelque chose du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

public class Money { public static short scale = 100;   protected long value;   public Money(long dollar, int cents) { value = (dollar * scale) + cents; }   public long dollars() { return value / scale; }   public short cents() { return (short) ((value * 100) / scale - (100 * dollars())); }   public Money add(Money rs) { return new Money(this).addSet(rs); }   public Money sub(Money rs) { return new Money(this).subSet(rs); }   private Money addSet(Money rs) { value += rs.value; return this; }   protected Money subSet(Money rs) { value -= rs.value; return this; } }

---

Avec ensuite d'autres méthodes utilitaires, pour les arrondis, pour partir d'un String, d'un double, ... ou convertir dans d'autres formats ou encore comparer.

Pour moi, c'est beaucoup plus clair d'utiliser une telle classe qui entre dans la logique monétaire plutôt que directement BigDecimal.

P.S. La classe est involontairement incomplète, je ne peux pas distribuer la version complète de cette classe, désolé.

Ah oui excellent, vais faire ça !
merci