Discussion :

[alf_idsoft]

Bonjour

Je viens de me prendre la tête sérieusement avec un problème de nombre décimal et les inventions de chiffres derrière la virgule par Delphi.

Je dois ré-écrire des calculs Delphi en PL/SQL (Oracle). Je fais une procédure stockée permettant de comparer les résultats obtenus par les 2 méthodes (résultats stockés dans 2 tables Oracle différentes).
Et j'ai des petites différences... Je débuggue, analyse les valeurs et là, je tombe sur 1.39999997. Hein ???
On a une fonction Delphi qui renvoie un single, qui fait tout un tas de calcul et qui renvoie 1.3, 1.4, 1.5... dans ce style-là, directement, sans calcul. Et dans une autre fonction on stocke dans un single le résultat de cette 1ère fonction : 1.3999... RoundTo : pareil ! Autres trucs équivalent : même valeur ! Je multiplie par 10, je passe par un entier. Pas mieux ! Je prend un 2ème single dans lequel je met entier/10 et encore la valeur bidon

Je cherche sur le forum, je trouve des problèmes +/- semblables à la pelle mais je trouve la solution tout seul : j'ai mis un double pour ma variable qui reçoit le résultat de ma fonction en single et ça fonctionne.

[e-ric]

Salut

Les nombres en virgule flottante sont par nature imprécis puisqu'ils sont une approximation avec un nombre fixé de bits, cela permet d'avoir des nombres avec un encombrement limité et des calculs dans un temps raisonnable.

Attention, si je me souviens bien, Oracle emploie une représentation en BCD, dans laquelle chaque demi-octet est un chiffre de 0 à 9 et le nombre de décimales est fixé, cela est moins efficace car les processeurs Intel ne supportent pas nativement cette représentation.

Delphi 7 dispose d'une bibliothèque d'émulation pour les BCD mais bof... elle est boguée.

@+

[alf_idsoft]

Cela faisait longtemps que je n'avais pas eu de problème de précision avec Delphi. Mettre 1.4 "en dur" dans une variable, et l'évaluer directement avec 1.39999997, c'est lamentable ! Rien qu'un détail comme celui-là, qui se contourne +/- bien, je serais chef de projet dans une banque : ce serait delphi ou moi !
Vous ne savez pas le pire ? Le programme fait un FinKey sur une table de paramétrage et il trouve un enregistrement ! Il va chercher le paramétrage 1.3 au lieu du 1.4.
On appelle ça déterrer des cadavres : on balance des informations fausses depuis des années sans que personne n'y aie vu quoi que ce soit.

[Eric Boisvert]

je serais chef de projet dans une banque : ce serait delphi ou moi !

Peu importe le langage de programmation, vous aurez à vivre avec ce genre de problème. Pour comparer 2 nombres en virgule flottante, on doit les soustraitres et comparer avec une tolérence.

Code :

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

1
2
3
4
5
 
Function CompareFloat(a: single; b: single; Epsi: single = 0.001): boolean;
Begin
  result := abs(a - b) < Epsi;
End;

[alf_idsoft]

ça me rappelle quand je m'amusais sur ma (calculatrice) TI85, j'étais confronté à cette marge d'erreur.
La, c'est bien + grave, on stocke 1.4 en dur dans une variable et on lui demande aussitôt combien elle vaut et c'est différent.
Je suis loin d'avoir fait le tour de tous les langages, j'ai toujours bien apprécié Delphi, mais je n'ai jamais vu ça ailleurs

[Eric Boisvert]

La problèmatique est bien démontrée ici

http://cpp.developpez.com/redaction/...ant/flottant1/

Bonne Lecture

[e-ric]

Comme le dit Eric Boisvert, ce n'est pas un problème de langage, C aurait le même problème (Delphi est hors de cause ), lié à la représentation des nombres en virgule flottante.

Petite parenthèse "méthodoloqique" : définir une clé de recherche avec un champ en virgule flottante, c'est pas fier et c'est prendre des risques, la preuve!! Il me semble que FindKey peut faire une recherche sur un intervalle sous certaines conditions mais c'est à vérifier, ça fait longtemps que je n'ai pas regardé ça. En tenant compte des remarque d'Eric, il y a alors moyen de faire.

@+

[alf_idsoft]

Oh punaise
Donc rien ne dit que je ne ferai pas avoir de la même manière sur un autre langage dans 10 ans
Un floatword de 0 à 655.35 et j'aurai été content

[alf_idsoft]

Honnêtement, je ne me rappelle pas avoir utilisé findkey (ce n'est pas moi qui avait codé), cela m'a carrément étonné qu'il fonctionnait avec ce nombre bancal
Je remplace du Delphi par du Oracle et je dois malheureusement corriger des détails dans le programme d'origine pour pouvoir correctement blinder les résultats : s'il y a une différence à la fin, soit j'ai mal retranscrit, soit j'ai corrigé malgré moi un bug en changeant de langage.
Changer un findkey par un locate... cela ne sert à rien puisque le programme Delphi ne sera plus utilisé

[Eric Boisvert]

Mon avis à tous...

Lorsque vous croyez qu'il y a un bug dans un langage quelconque....
Je vous invite à approfondir la problématique en question....

C'est habituellement un concept mal compris qui vous attend...

Un vrais bug dans un langage est habituellement relié à un contexte très
particulier... et de ce fait... seulement quelque malchanceux tombe dessus...
sinon, le distributeur du logiciel émet habituellement rapidement, une mise à jour de son produit....

(Cette mise en garde déborde largement le sujet en cours bien sûre)

Désolé... c'était plus fort que moi.

[alf_idsoft]

C'est bien de le dire
Depuis le temps que je suis dans le métier, se pourrir une matinée pour un réel approximatif, ça agace et c'est vrai que la 1ère réaction (pas seulement la mienne au boulot), c'était de râler sur Delphi.
Rien à voir avec le sujet, mais il y a des bugs en Delphi : je suis resté à la version 7, mais rien qu'un recordcount, ça ne fonctionne pas terrible. Je n'ai jamais creusé pourquoi c'était comme cela, juste toujours fait autrement.

[e-ric]

Pourtant les problèmes liés aux nombres en virgule flottante ne sont pas nouveaux... C, C++ et tous les langages qui s'appuient sur la représentation native des processeurs en micro auront les mêmes soucis. Une solution consisterait à mettre en place sa propre représentation des nombres, mais bonjour le travail et il vaut mieux être fort en maths.

C'est Intel et AMD à qui il faut demander des comptes, les langages de programmation ne font que se plier à ce qu'offrent les processeurs.

Quant au Recordcount, il faut lire la doc, ce qui inclut les sources de la VCL (TDataSet par exemple). Il faut savoir que les SGBD n'offrent pas les mêmes solutions face au même problème, disons que RecordCount en fait partie et qu'il est mis en place à l'origine pour les tables Paradox. Pour les bases Access, à une époque je ne sais si c'est encore valable, il fallait exécuter Dataset.Last avant de connaître la bonne valeur de RecordCount. C'est une fonctionnalité qu'il vaut mieux bannir surtout dans un environnement concurrentiel (aui sens de la base de données).

Quand une fonctionnalité ne marche pas idéalement, cela peut être un bug mais pas toujours...

Cdlt

[ShaiLeTroll]

Pour le RecordCount, je confirme sous DBExpress + Sybase, il ne fonctionne quasiment jamais !
En BCB2007, j'avais quelques cas basiques qui passait, je crois que j'en ai encore moins depuis XE2 mais la documentation de DBExpress prévient que RecordCount est capricieux !

On en a rarement besoin, une boucle sur EOF\Next suffit mais cela empêche des optimisations comme pré-allouer un tableau par exemple ou utiliser Capacity d'une TList

Pour les erreurs d'arrondis sur les valeurs à virgule flottante, un débat qui revient souvent !