Discussion :

[droliprane]

Bonsoir à tous,

quand je créé une ordre de fabrication, j'enregistre dans une table nof (nomenclature of) les différentes qtés de matière/fourniture dont j'aurai besoin pour fabriquer l'of en question.

Dans le cas qui me pose problème, j'ai un produit P qui se fabrique à partir de 0,2 mètre d'une barre de laiton.

J'ai donc cette partie de code :

Code :

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

1
2
3
4
5
6
7
8
9
Trace(SAI_qte + " x " + Rs.nmcl_qte_lien + " = " + (SAI_qte * Rs.nmcl_qte_lien  ))
HRAZ(nof)
nof.nof_of_id = ofid
nof.nof_op = Rs.nmcl_op
nof.nof_fourniture = Rs.nmcl_fourniture
nof.nof_qte_lien = Rs.nmcl_qte_lien
nof.nof_qte_necessaire = SAI_qte * Rs.nmcl_qte_lien  
nof.nof_qte_utilisee = 0
HAjoute(nof)

Et voici ce qui s'enregistre en base SQL Server, quand je créé successivement des OF de 4, puis 14, puis 24, puis 4 produits P :



Alors je veux bien contourner le problème en mettant un arrondi dans l'histoire, mais d'une part je voudrais comprendre pourquoi ça se comporte comme ça, et d'autre part ça ne me rassure pas que du "bruit" vienne s'introduire dans un calcul simple...

Merci à vous pour votre aide.

[Hibernatus34]

Bonjour,

C'est probablement parce que vous utilisez le type réel (ou "numérique" dans l'IHM). C'est un type en base 2. Ce qui veut dire que les chiffres après la virgule ne sont pas des décimales (x/10, y/100, z/1000...), ce sont x/2, y/4, z/8, etc.
Ce type est très précis, mais pas exact sur des valeurs en base 10 comme on utilise souvent.

Utilisez le type numérique ("numérique haute précision" dans l'IHM) et faites attention aux valeurs immédiates (n'écrivez pas "0.2" mais "0n0.2").

PS. Evitez le type monétaire dans l'analyse, il y a un bug extrêmement grave dans WD17 x64 qui fausserait tous vos chiffres lors des HAjoute.

PS. Voici une petite illustration à tester directement dans Management Studio :

Code :

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

1
2
3
4
5
6
7
CREATE TABLE #bob (bill FLOAT)
INSERT INTO #bob VALUES (0.2)
CREATE TABLE #bret (bill DECIMAL(20,16))
INSERT INTO #bret SELECT 24 * bill FROM #bob
SELECT * FROM #bret
DROP TABLE #bob
DROP TABLE #bret

[droliprane]

Bonjour,

et merci pour votre aide. Effectivement, j'ai coché la case "Numérique haute précision (38 chiffres significatifs)" pour mon champs qté OF (celui où je mettais 14 par exemple) et ça m'a bien enregistré 2,8 dans la table.

Par contre, je ne comprends pas la remarque :

faites attention aux valeurs immédiates (n'écrivez pas "0.2" mais "0n0.2").
[/code]

je vais quand même pas faire saisir aux utiliateurs 0n.02 !?

et l'autre remarque :

PS. Evitez le type monétaire dans l'analyse, il y a un bug extrêmement grave dans WD17 x64 qui fausserait tous vos chiffres lors des HAjoute.
[/code]

Evitez le type monétaire dans l'analyse, vous parlez du type des champs de la table ? Parce que moi je suis sous SQL Server, et j'ai que des types float. Par contre, dans mon IHM j'ai certains champs avec le type monétaire... Est-ce que c'est gênant ?

Merci à vous

[Hibernatus34]

Pour "0n0.2", c'est uniquement dans votre code, parce qu'une valeur a beau être immédiate, elle a un type. Ecrire "24" est équivalent à déclarer/initialiser/utiliser un entier de valeur 24. Ecrire "0.2" est équivalent à utiliser un réel. (qui ne vaut pas exactement 0.2 en réalité, car c'est pas possible en base 2)

Par exemple :

Code :

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

1
2
Trace("0.2 * 24 = " + NumériqueVersChaîne(0.2 * 24, ",16f"))
Trace("0n0.2 * 24 = " + NumériqueVersChaîne(0n0.2 * 24, ",16f"))

Pour le type monétaire dans l'analyse, je parle de la description de la base de données, appelée "analyse" dans WinDev.
Si vous déclarez une rubrique de type monétaire dans cette analyse, WinDev exécutera les HAjoute (au moins) de manière incorrecte en OLE DB et en 64 bits, perdant l'exposant des nombres ronds : 300.0 deviendra 3.0. Ce bug n'est plus là en WD18.
Je ne parle ni du code, ni de l'IHM.

[Nicolas_Jeanneau]

Bonjour,

j'ai le même problème et pour palier à cela j'ai dû enregistrer les valeurs en numeric (18,2) pour garder 2 décimales uniquement.
Le type monétaire est enregistré dans des valeurs également en numeric (18,2) pour garder une cohérence dans mes données et mes types.

Concernant les chaîne de caractères, c'est aussi un problème : j'ai dû transformer mes champs en varchar pour ne pas ramener une flopée d'espaces après la chaîne du champ ...

Pourtant j'utilise l'accès natif mais c'est quelque chose que je ne soupçonnais pas lors de mes tests ...

bon courage,

Nicolas

[droliprane]

Pour "0n0.2", c'est uniquement dans votre code, parce qu'une valeur a beau être immédiate, elle a un type. Ecrire "24" est équivalent à déclarer/initialiser/utiliser un entier de valeur 24. Ecrire "0.2" est équivalent à utiliser un réel. (qui ne vaut pas exactement 0.2 en réalité, car c'est pas possible en base 2)

Par exemple :

Code :

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

1
2
Trace("0.2 * 24 = " + NumériqueVersChaîne(0.2 * 24, "4,16f"))
Trace("0n0.2 * 24 = " + NumériqueVersChaîne(0n0.2 * 24, "4,16f"))

Pour le type monétaire dans l'analyse, je parle de la description de la base de données, appelée "analyse" dans WinDev.
Si vous déclarez une rubrique de type monétaire dans cette analyse, WinDev exécutera les HAjoute (au moins) de manière incorrecte en OLE DB et en 64 bits, perdant l'exposant des nombres ronds : 300.0 deviendra 3.0. Ce bug n'est plus là en WD18.
Je ne parle ni du code, ni de l'IHM.

Ok donc c'est uniquement dans le code, dans ce que j'appelle des affectations par défaut.

Par contre, j'ai une partie gestion commerciale dans mon appli (saisie de commande, bl, ...) donc à chaque fois que j'ai un champs de saisie de type numérique, j'ai vraiment intérêt à tous les flagger comme étant des "haute précision", c'est bien ça ?

Quand à l'analyse, je n'ai pas conçu mon analyse dans WinDev, c'est seulement un rapatriement de la structure des tables depuis SQL Server, donc je ne devrais pas être embêté.

Merci beaucoup pour vos explications

[Hibernatus34]

Si vous faites "HAjoute(nof)", c'est que vous avez une analyse.
Vérifiez le type des rubriques.
Après, vous n'avez peut-être pas toutes les conditions pour reproduire le bug, par exemple si vous ne faites que du 32 bits.

Pour les champs de saisie, oui, il est préférable de tout passer en numérique haute précision. Dans la plupart des cas, par le jeu des conversions et arrondis implicites, vous n'aurez pas de problème, mais si vous voulez être sûr de vous...

[DelphiManiac]

Bonjour,

C'est probablement parce que vous utilisez le type réel (ou "numérique" dans l'IHM). C'est un type en base 2. Ce qui veut dire que les chiffres après la virgule ne sont pas des décimales (x/10, y/100, z/1000...), ce sont x/2, y/4, z/8, etc.
Ce type est très précis, mais pas exact sur des valeurs en base 10 comme on utilise souvent.
...

Très bonne explication d'Hibernatus, je tiendrais juste à préciser que ce problème n'est en rien lié à l'outil utilisé.

En gros, tant que l'on reste avec les types de bases numériques (float et double) il faut faire gaffe à ces erreurs de calcul de partout.

Juste pour exemple, prenez Excel et tapez la formule suivante dans une cellule : =(5-4,9)-0,1 (faites attention à ce que la cellule soit en format standard), le résultat qui apparaît est -3,60822E-16, pour le moins étonnant au premier abord ^^

[droliprane]

Si vous faites "HAjoute(nof)", c'est que vous avez une analyse.
Vérifiez le type des rubriques.
Après, vous n'avez peut-être pas toutes les conditions pour reproduire le bug, par exemple si vous ne faites que du 32 bits.

Pour les champs de saisie, oui, il est préférable de tout passer en numérique haute précision. Dans la plupart des cas, par le jeu des conversions et arrondis implicites, vous n'aurez pas de problème, mais si vous voulez être sûr de vous...

Oui j'ai bien une analyse, et tout mes champs de type float Sql Server, sont typés en rééels sur 8 octets dans mon analyse. Est-ce que c'est bon ?

Autre chose, j'ai paramétré mon projet pour que l'exécutable généré soit un 32bits (je ne sais plus pourquoi mais ça me posait problème pour certaines librairies qui ne fonctionnaient pas en 64). Est-ce que quand je lance l'appli en test (Ctrl+F9) je suis aussi en 32bits ? Ou bien est-ce seulement l'exécutable qui sera en 32 et quand je teste je suis en 64 ?

Merci

[Hibernatus34]

Le mode 32/64 bits dépend de la configuration, et s'applique aussi bien à l'exécutable final qu'à celui de test (WDTst).

Le type FLOAT dans SQL Server est exactement un réel sur 8. (ou réel tout court dans WD)
Mais ça signifie qu'il est inutile de passer par des numériques haute précision, car le FLOAT est du binaire (base 2), et donc les approximations seront toujours là.

Dans un tel cas, ces approximations doivent être "masquées" par l'affichage. Par exemple, on n'affiche jamais plus de 6 chiffres après la virgule, et personne ne verra que c'est du binaire, et les calculs resteront justes également. (pour la précision demandée, c'est à dire 10^-6)

A moins que vous ayez la possibilité de changer le type des données dans la base, en passant à du DECIMAL (et donc Numérique dans l'analyse WD).

[droliprane]

Bizarre alors parce je suis en configuration exécutable Windows 32bits, et je rencontrais quand même ce problème...

Le type decimal serait mieux que le type float ? Bon je suis le seul à développer et à concevoir la bd donc oui je pourrais passer tous mes champs de float à decimal, mais ça me fais pas mal de boulot !

Sinon, les updates de WinDev n'ont pas corrigé ce problème ? Même les toutes dernières ?

Si je passais en v18 ça m'éviterait toutes ces modifs ? Par contre j'ai jamais réussi à importer un projet dans une version plus récente, ça se passe jamais bien. M'enfin ça c'est un autre problème !

[Hibernatus34]

Attention à ne pas mélanger tout ce que j'ai dit.
Il y a 2 choses complètement distinctes :

1. Le type réel (WD) ou FLOAT (SQLServer) est un type binaire, et non décimal, ce qui explique une approximation des nombres que nous écrivons en décimal.
Cette approximation n'est pas gênante la plupart du temps et n'apparaît pas à l'utilisateur grâce à des arrondis implicites et une précision plus que suffisante.
Quelle que soit la version de WD, et même quel que soit l'outil de développement (cf. la requête de mon 1er message), ce "problème" demeurera.


2. Il y a un bug, un vrai, dans WD17 x64, qui fait qu'il va stocker dans la base 42.0 à la place de 42000.0 dans certaines conditions. L'une des conditions nécessaires à ce bug est d'avoir déclaré le type monétaire dans l'analyse, au lieu de numérique.
Puisque c'est un bug, ça ne devait pas perdurer, et ça a été corrige en 18.
Selon moi, ça aurait dû être corrigé en 17, vu la gravité d'un tel bug.

[DelphiManiac]

...
Dans un tel cas, ces approximations doivent être "masquées" par l'affichage. Par exemple, on n'affiche jamais plus de 6 chiffres après la virgule, et personne ne verra que c'est du binaire, et les calculs resteront justes également. (pour la précision demandée, c'est à dire 10^-6)...

Je ne suis pas vraiment d'accord avec cette remarque, surtout sur la partie "et les calculs resteront justes".

Les calculs seront toujours faux, quelque soit la manière d'afficher les données. Le piège n'est pas tant au niveau de l'affichage, mais au niveau du code quand on commence à faire des tests sur les résultats du calcul. Si l'on prend l'exemple précédent, c'est à dire que l'on calcule

Code :

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

1
2
f est un réel
f = (5 - 4.9) - 0.1

et que l'on affiche max 6 décimales, on aura bien 0, mais si dans le reste du code, on teste à un moment ou à un autre

Code :

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

1
2
3
si f = 0 alors
//
fin

là on aura un bug, tout simplement parce qu'a ce moment, on aura complètement oublié le souci potentiel.

Le problème est donc à prendre dans sa globalité, ce n'est pas juste un problème de présentation des données à l'utilisateur.

[Hibernatus34]

Les calculs seront toujours faux, quelque soit la manière d'afficher les données. Le piège n'est pas tant au niveau de l'affichage, mais au niveau du code quand on commence à faire des tests sur les résultats du calcul. Si l'on prend l'exemple précédent, c'est à dire que l'on calcule

Code :

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

1
2
f est un réel
f = (5 - 4.9) - 0.1

et que l'on affiche max 6 décimales, on aura bien 0, mais si dans le reste du code, on teste à un moment ou à un autre

Code :

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

1
2
3
si f = 0 alors
//
fin

là on aura un bug, tout simplement parce qu'a ce moment, on aura complètement oublié le souci potentiel.

C'est vrai, même si ce test fonctionne correctement sous WinDev.
Dans le cas d'un type binaire, les égalités devraient être faites avec le même arrondi que celui utilisé pour les entrées/sorties.

[droliprane]

oui entièrement d'accords DelphiManiac.

Moi pour assurer le coup, je vais coller tous mes champs numérique en haute précision. Déjà je vais éliminer une bonne partie des soucis je pense.
¨
Par contre, est-ce que je vais alourdir l'appli, ou bien le traitement des données ?

[Hibernatus34]

oui entièrement d'accords DelphiManiac.

Moi pour assurer le coup, je vais coller tous mes champs numérique en haute précision. Déjà je vais éliminer une bonne partie des soucis je pense.
¨
Par contre, est-ce que je vais alourdir l'appli, ou bien le traitement des données ?

Le réel est un type natif, donc plus rapide que le décimal.
Mais la part des calculs dans l'exécution sera probablement infime et il est inutile de se faire des cheveux blancs à ce sujet.

[DelphiManiac]

C'est vrai, même si ce test fonctionne correctement sous WinDev.

J'avoue ne pas avoir lancer mon test sous Windev, ce que je viens de faire, et le résultat est encore plus imprévu ^^ La valeur n'est pas égale à 0, mais le test d'égalité à 0 renvoie vrai, affolant par contre là :p

Code :

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

1
2
3
4
5
6
7
8
9
f est un réel
f = (5-4.9)-0.1
Trace(f)
 
SI f=0 ALORS
	Trace("f=0")
SINON
	Trace("f<>0")
FIN

Résultat :

Code :

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

1
2
-0.0000000000000003608224830032
f=0

Ce code là est pour le moins perturbant :

Code :

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

1
2
3
4
5
SI 0.0000001 = 0.00 ALORS
	Trace("égal")
SINON
	Trace("différent")
FIN

Devinez le résultat

Comportement pour le moins aberrant. Moralité, il faut vraiment prendre le maximum de précautions quand on manipule des réels.

P.S.: Windev doit considérer par défaut que 0.00 est un décimal et pas un réél, (les décimaux de Windev ayant 6 chiffres décimaux significatif dans windev), Windev doit donc convertir la valeur 0.0000001 en décimal et du coup l'égalité avec 0 est valide, mais bon ce fonctionnement sur des valeurs littérales est pour le moins tiré par les cheveux.

[Hibernatus34]

Ce n'est pas si aberrant, c'est intuitif et correct dans le cas général, conformément à l'esprit de WinDev.

Il est aussi aberrant de faire des calculs avec des chiffres après la virgule pour ensuite tester une égalité parfaite, sachant que des chiffres après la virgule impliquent des approximations.

[Nicolas_Jeanneau]

Je voudrais juste intervenir sur le calcul : il m'arrive de chercher à vérifier si la somme de certains montants est égale à une valeur stockée. Si je reste en réel, cela n'est (pratiquement) jamais le cas. Il faut systématiquement que j'arrondisse mon calcul ET ma valeur stockée en BDD ... car sinon mon égalité n'est pas vérifiée et mon traitement afférent n'est pas exécuté. Si au moins ma valeur stockée était correctement stockée, je ne me poserai pas ces questions, d'où mon stockage en numeric(18,2) dans SQL Server et là je n'ai plus d'arrondi à faire et des données correctes en base.

[droliprane]

ce qui se passait pour moi, c'est que j'avais une "qté nécéssaire" calculée par WinDev (2,800000003) et stockée dans la table, et qui en apparence dans l'ihm affichait 2,8.

Ensuite, l'utilisateur doit pouvoir accumuler de la qté dans un champs "qté affectée".

Enfin, un champs "Reste à affecter" faisait le calcul de la différence. Et cette différence, dans la table et aussi dans ma requete sql, elle est non nulle (2,8000000003 - 2,8 = 0,0000000003). Et ma table est sensée n'afficher que les fournitures qui ne sont pas encore complètement affectées, du coup j'avais cette ligne en trop, avec pourtant la colonne RESTE à 0, mais seulement en apparence dans l'ihm...