Discussion :

[Anselme45]

Bonjour à tous,

J'ai une app Android qui demande à l'utilisateur de saisir un nombre réel mais au final j'obtiens un nombre réel avec des décimales erronées. Pour une saisie "0.3", je me retrouve avec une valeur *0.30000001"!!!

Je bricole le bout de code suivant pour visualiser ce qui se passe:

Code :

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

1
2
3
4
5
6
7
 
var
 mysingle: single;
...
mysingle:=StrToFloat(StringReplace(String(DataInput.Text),'.',FormatSettings.DecimalSeparator,[])); 
 
FinalValue.Text:=FloatToStrF(mysingle, ffGeneral, 8, 3,G_myDecimalSeparator);

Je saisie dans DataInput.text le string "0.3* et j'obtiens dans FinalValue.Text le string *0.30000001"!!!

Questions:

1. Comment éviter ce problème de précision?

2. Avec la mention "FloatToStrF(...8,3...", je devrais bien avoir 3 digits après la virgule, non?

[Andnotor]

D'après l'aide, la précision doit être inférieure ou égale à 7 pour un single.

[solilog]

Bonjour,

La précision d'un nombre réel est assurée par la fonction RoundTo dans l'unité Math.

Code :

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

1
2
3
4
5
6
7
8
 
uses Math;
..
..
FinalValue := RoundTo(1230.765 ), -2);   // = 1230.76 
FinalValue := RoundTo(1230.765 ), -4);   // =  1230.7650 
FinalValue := RoundTo(1230.765 ), 0);    // = 1230
FinalValue := RoundTo(1230.765 ), 2);    // = 1200

solilog

[ALWEBER]

Désolé tu ne peux rien faire.
L'exemple ci-dessous n'est pas particulier à Delphi. Le processeur effectue les calculs en base 2. On sait donc exprimer un demi, un quart, un huitième, etc. soit 1 / 2^n mais on ne sait pas décrire 1/10 ou 1/100 qui sont des nombres incommensurables en base 2. Voilà donc un résultat surprenant.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
…
var
  i1, i2: Extended ;
begin
  readln (i2) ;
  i1 := i2 + i2 + i2 + i2 + i2 - 0.05 ;
  writeln (FloatToStr(i1));
  readln ;
end.

Entrer la valeur 0.01
Donc 0.01+0.01+0.01+0.01+0.01-0.05=0
En fait le résultat donne
-3.3881317890172E-21
Pareil pour excel et autres

[Anselme45]

Merci à tous pour vos réponses

J'ai fini par réussir à avoir un "0.3" quand l'utilisateur tape "0.3" (expliquer comme cela, j'ai l'impression d'avoir réaliser un exploit digne de junior qui fait son premier rôt!)

Il faut...

1. Remplacer le type single par un type currency

2. Appliquer la fonction RoundTo

[Bernard B]

Bonsoir,

J'ai rentré la formule d'Alweber dans une case de LibreOffice Calc : =0,01+0,01+0,01+0,01+0,01-0,05 et même en format scientifique j'ai bien 0 comme résultat ou plus exactement 0,00E+00.

[Charly910]

Bonjour,

idem pour moi : dans mon Excel2000 : =0,01+0,01+0,01+0,01+0,01-0,05 = 0,00000000000E+00 ?
je ne sais pas comment Excel se débrouille. Il faudrait tester avec un Excel récent !!!

A+
Charly

[ShaiLeTroll]

Excel utilise un Double : L’arithmétique à virgule flottante peut entraîner des résultats imprécis dans Excel
Et il y a justement un article sur Nombres binaires périodiques et calculs ayant des résultats proches de zéro
Vous pensez bien qu'un outil de bureautique a été extrêmement travaillé pour gérer ce genre de problème connu depuis l'avènement des calculs en nombre flottant
Et à l'affichage, on peut penser qu'Excel considère certaines valeurs avec une précision proche de la marge d'erreur comme devant être affiché plus simplement, un double ayant une précision de 15 digits

Ce n'est pas un problème Android mais un problème lié au IEEE 754 :
Problème d'arrondi en Delphi
Utilisation de l'arrondi sur un calcul
roundto simperoundto currency arrondi incorrect
Round : arrondir à l'entier supérieur quand on est à 0,5 ?

mais comme répété plusieurs fois, l'astuce est d'arrondir deux fois, typiquement, les calculs sont effectués sur 4 digits de plus que nécessaire, le premier arrondi sur 2 digits supplémentaires et enfin l'arrondi à 0 digits
Ensuite TOUJOURS utiliser un Compare avec Epsilon pour définir la précision souhaité dans les calculs, ne jamais utiliser une valeur flottante brute, elle requiert un soin particulier pour la rendre pertinenete

Par exemple, le calcul du taux change de l'Euro lors de son instauration en France
6,55957 * 1.01, soit 7 digits potentiels lors de la conversion des centimes, il faut choisir un au moins 11 digits après la virgule, un Double fera l'affaire

6,6251657, on arrondi à 6,625167 puis à 6,6252, ça c'est le Currency un format monétaire transitoire
comme l'usage veut que l'on n'affiche que les centimes 6,62 sera affiché mais l'on conserve 0,0052 sur un compte d'arrondi, si l'on stocke aussi la valeur arrondie

Le Currency n'est pas un format flottant, c'est un calcul entier avec une simulation d'une virgule à 4 digit
Il est typiquement conçu pour la calcul de montant avec potentiellement des nombres de type 1.01 x 1.01, la gestion des centimes sur 4 digits pour assurer un arrondi sur 2, et même dans ce cas, ce n'est pas l'arrondi mathématique qu'il faut utiliser mais l'arrondi bancaire.
Cela fait débat : Arrondi classique vs Arrondi bancaire

[ALWEBER]

Bonjour,
idem pour moi : dans mon Excel2000 : =0,01+0,01+0,01+0,01+0,01-0,05 = 0,00000000000E+00 ?
je ne sais pas comment Excel se débrouille. Il faudrait tester avec un Excel récent !!!
A+
Charly

Voici le fichier pour tester
Les deux autres valeur du fichier sont égales à 1/2^n donc le résultat est OK

[ShaiLeTroll]

Il faut différencier l'affichage de la valeur brute comme l'a mis en évidence ALWEBER
Excel calcule avec un Double avec les problèmes connus mais est assez malin pour afficher une valeur corrigée, pour la plupart des utilisateurs c'est convenable
mais pour les calculs, il ne peut pas se permettre d'arrondir