Erreur de calcul sur Single (ou Double)

Quelqu'un peut-il m'expliquer ?

Code:

---

1 2 3

Dim N1 As Single = 135.68 Dim N2 As Single = 0.59 Dim N3 As Single = N1 * N2

---

Normalement, on devrait obtenir N3=80.0512
Eh ben non ! VB trouve que N3=80.05119 !!!

EDIT :
Bon j'ai trouvé une réponse ici :
http://msdn.microsoft.com/fr-fr/libr...v=vs.100).aspx
Mais ça va pas simplifier mon analyse.

Salut au risque de me faire lincher par les spécialistes,

Tu peux tout multiplier par 100 ou 1000 par exemple si tu sait combien tu a de chiffre apres la virgule au maximum, on se sert pas de cette technique en embarqué, en plus les calcule sur les entier sont bien plus rapide :mrgreen:

Citation:

---

Envoyé par chaparo

Tu peux tout multiplier par 100 ou 1000 par exemple si tu sait combien tu a de chiffre apres la virgule au maximum, on se sert pas de cette technique en embarqué, en plus les calcule sur les entier sont bien plus rapide :mrgreen:

---

En quoi le fait qu'on se serve ou pas d'une technique en embarqué la qualifie ou la disqualifie ?

Par ailleurs dans la mesure où tu ne sais pas ce qu'il va faire de ces valeurs derrières, lui suggérer de multiplier tout par 100 ou 1000 me semble une idée plus que bizarre.

Si il applique par exemple des fonctions de calculs non linéaires derrières (et ça tu n'en sais rigoureusement rien) ta méthode ne marche pas.

Citation:

---

Envoyé par mdevaux62

Mais ça va pas simplifier mon analyse.

---

Si tu n'as pas des ordres de grandeurs très élevés/très petits à manipuler, utilise le type decimal en lieu et place de single ou double et tu n'auras pas ce problème.

Il faut comprendre que ces types à stockage mantisse-exposant sont plus destinés à du calcul physique (car ils peuvent manipuler des ordres de grandeur très grand ou très petit) qu'à du calcul financier, pour lequel les ordres de grandeur sont nettement plus petit mais on veut des valeurs décimales précises.

De plus, le type Single ne sert plus à grand chose de nos jours (bouffer 4 octets au lieu de 8 est devenu anecdotique), prendre le type double systématiquement, pour ce type de calcul.

Pour de la compta/gestion/finance (où on aime bien que 0 soit 0 et pas 0.00000000001, alors que en calcul physique on considére que c'est pas forcément important) le type decimal est plus adapté.

Citation:

---

N3=80.05119

---

En réalité, N3 = 80.05119999... , l'écart de 0.00...01 étant du à la précision des single.

Citation:

---

utilise le type decimal en lieu et place de single ou double et tu n'auras pas ce problème.

---

+1

Citation:

---

Envoyé par Bluedeep

En quoi le fait qu'on se serve ou pas d'une technique en embarqué la qualifie ou la disqualifie ?

---

Citation:

---

on se sert pas de cette technique en embarqué,

---

J'ai oublié une lettre
on se sert pas mal de cette technique en embarqué,

Citation:

---

Par ailleurs dans la mesure où tu ne sais pas ce qu'il va faire de ces valeurs derrières, lui suggérer de multiplier tout par 100 ou 1000 me semble une idée plus que bizarre.
Si il applique par exemple des fonctions de calculs non linéaires derrières (et ça tu n'en sais rigoureusement rien) ta méthode ne marche pas.

---

Citation:

---

Tu peux tout multiplier par 100 ou 1000 par exemple si tu sais combien tu as de chiffres après la virgule au maximum

---

J'ai bien précisé si il avait toujours le même nombre de chiffre après la virgule après il suffit de rediviser par le même nombre pour repasser en nombres décimaux.

Citation:

---

Envoyé par chaparo

J'ai bien précisé si il avait toujours le même nombre de chiffre après la virgule après il suffit de rediviser par le même nombre pour repasser en nombres décimaux.

---

Sauf que cette idée de diviser pour remettre le point décimal à sa place à la fin ne marche que si il n'applique pas de calcul non linéaire, comme je l'ai écrit supra.

Une simple élévation à la puissance invalide la méthode.

Sans même parler de la capacité limitée (concernant l'ordre de grandeur) des entiers dès lors que tu la réduit en considérant qu'une partie du contenu est constitué de décimal "fictives".

Bref, une façon très hasardeuse de procéder alors qu'il existe un type pour ce genre de calcul orienté gestion, c'est le type decimal.

Citation:

---

Envoyé par Bluedeep

Si tu n'as pas des ordres de grandeurs très élevés/très petits à manipuler, utilise le type decimal en lieu et place de single ou double et tu n'auras pas ce problème.

---

Le type Decimal fonctionne effectivement parfaitement pour ce que je dois faire.
Merci.

Citation:

---

Envoyé par mdevaux62

Le type Decimal fonctionne effectivement parfaitement pour ce que je dois faire.
Merci.

---

De rien.

Je t'invite à jeter un oeil ici, avec une démonstration très didactique concernant l'usage decimal vs float(single en VerBeux ;))

Et n'oublie pas de marquer la discussion comme résolue.

Bonjour,
ou ici pour se rendre compte de la précision d'un Single (Float pour ceux qui pratique le C#).
0.59 = 0x3F170A3D = 00111111 00010111 00001010 00111101
0.58999998 = 0x3F170A3D = 00111111 00010111 00001010 00111101
135.68 = 0x4307AE14 = 01000011 00000111 10101110 00010100
135.679987 = 0x4307AE14 = 01000011 00000111 10101110 00010100
Si le système restitue :
135.679987*0.58999998, l'erreur est juste.