PC SOFT

FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile

|
|
|
FR
Accueil → WINDEV 2025 → Problème de calcul
Problème de calcul
Débuté par ablanc, 15 sep. 2015 12:46 - 20 réponses
#1
Posté le 15 septembre 2015 - 12:46
Bonjour,

J'ai un problème avec un calcul :
xTauxTVA est numérique=5.5
xPrixHT est numérique

xPrixHT=5/ (1+xTauxTVA/100)
Trace(xPrixHT)// affiche 4 au lieu de 4.739...
xPrixHT=42/ (1+xTauxTVA/100)
Trace(xPrixHT)// affiche 39 au lieu de 39.810...
xPrixHT=1.04/ (1+xTauxTVA/100)
Trace(xPrixHT)// affiche 3.8 au lieu de 3.829...
xPrixHT= -1/ (1+xTauxTVA/100)
Trace(xPrixHT)// affiche 79228162532711081675843436543 !


Pourtant, j'ai vérifié et ces opérations me renvoient bien un type numérique, et pas un entier.

Trace(dbgInfo(dbgNomType,TypeVar(42/ (1+xTauxTVA/100))))


Quelqu'un peut-il me donner l'explication ?
Faut-il proscrire le type numérique de tout calcul financier ?
Je croyais justement qu'il était conçu pour cet usage.

>Merci d'avance pour votre aide.
Signaler
0
0
#2
Posté le 15 septembre 2015 - 14:09
Bonjour Alain

ton problème est un grand classique

Quand tu fais :
xPrixHT = 5 / (1 + xTauxTVA / 100)

Tu mets bien le RESULTAT du calcul dans un numérique...

Mais rien ne dit dans quel type de variable les calculs INTERMEDIAIRES
sont faits, et comme tu as 3 opérateurs sur ta ligne, sans compter les
parenthèses, le compilo prend des décisions tout seul...

Et dans ce cas, il semble qu'il décide d'utiliser des variables
intermédiaire de type entier

il faut donc plutot faire le calcul suivant pour être SUR que tout se
passe dans des numériques.

xPrixHT = 1+ tauxTVA
xPrixHT = xPrixHT/100
xPrixHT = 5/ xPrixHT

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information surhttp://fabriceharari.com

On 9/15/2015 4:46 AM, Alain Blanc wrote:
Bonjour,

J'ai un problème avec un calcul :
xTauxTVAestnumérique=5.5
xPrixHTestnumérique

xPrixHT=5/ (1+xTauxTVA/100)
Trace(xPrixHT)// affiche 4 au lieu de 4.739...
xPrixHT=42/ (1+xTauxTVA/100)
Trace(xPrixHT)// affiche 39 au lieu de 39.810...
xPrixHT=1.04/ (1+xTauxTVA/100)
Trace(xPrixHT)// affiche 3.8 au lieu de 3.829...
xPrixHT= -1/ (1+xTauxTVA/100)
Trace(xPrixHT)// affiche 79228162532711081675843436543 !


Pourtant, j'ai vérifié et ces opérations me renvoient bien un type
numérique, et pas un entier.

Trace(dbgInfo(dbgNomType,TypeVar(42/ (1+xTauxTVA/100))))


Quelqu'un peut-il me donner l'explication ?
Faut-il proscrire le type numérique de tout calcul financier ?
Je croyais justement qu'il était conçu pour cet usage.

>Merci d'avance pour votre aide.
Signaler
0
0
#3
Membre enregistré
952 messages
Posté le 15 septembre 2015 - 14:15
Bonjour Alain,

je viens de tester en WD18 ( je ne dispose pas de WD20 ) effectivement c'est space.
j'ai l'impression que les divisions de Numérique, c'est un peu flou !!

essayer ceci :

xTauxTVA est numérique=5.5
xPrixHT est numérique

xPrixHT=5/ (1+ (xTauxTVA*0.01))
Trace(xPrixHT)// affiche 4.739336 au lieu de 4.739...

xPrixHT=5/ (1+ (xTauxTVA/100))
Trace(xPrixHT)// affiche 4 au lieu de 4.739...


le simple fait de ne pas diviser votre taux de tva par 100 mais de le multiplier par 0.01 solutionne le problème ^^

mais perso, j'éviterai ce type de variable !!:D

>Bon dèv
Signaler
0
0
#4
Posté le 15 septembre 2015 - 16:29
Bonjour Fabrice,

Merci pour la réponse, mais je pense que le diagnostic est erroné :
xTauxTVA est numérique=5.5

// Chaque noeud de l'expression renvoie un Numérique :
Trace(dbgInfo(dbgNomType,TypeVar(xTauxTVA/100)))
Trace(dbgInfo(dbgNomType,TypeVar(1+xTauxTVA/100)))
Trace(dbgInfo(dbgNomType,TypeVar(5/ (1+xTauxTVA/100))))

// En n'utilisant que des numériques à virgule flottante dans l'expression on a le même problème :
xUnest numérique(*) =1
xMoinsUnest numérique(*) = -1
xCentest numérique(*) =100

Trace(xMoinsUn/ (xUn+xTauxTVA/xCent))

// Même chose avec des littérales numériques :
Trace(-0n1/ (0n1+0n5.5/0n100))


Ce code montre qu'on reste toujours sur du numérique, et qu'une expression où toutes les opérandes sont du numérique pose le même problème.

C'est pas un peu dangereux pour nos applications de gestion ?

>Merci d'avance pour votre aide.
Signaler
0
0
#5
Posté le 15 septembre 2015 - 16:49
Bonjour

Non, mon diagnostic est correct, et ton code le prouve.

Comme je te le disais, le problème est dans les calculs à plusieurs
opérateurs qui obligent le compilo à utiliser des variables intermédiaires.

Tu as assumé que le fait de placer chaque valeur dans une variable de
type NUMERIQUE obligerait le compilo à utiliser des variables
intermédiaires de ce type, et ce n'est tout simplement pas le cas.

Il ne faut pas oublier que le compilo actuel est un descendant direct de
celui utilisé il y a 20 ans quand les numériques ou monétaires
n'existaient même pas. Son code privilégie clairement toujours les réels
et entiers pour les variables intermédiaires, comme ça a toujours été le
cas.

Pour des simples raisons de compatibilité ascendante, je doute que ca
change un jour.

Mon exemple de code, par contre, fonctionne parfaitement parce que
aucune variable intermédiaire n'est utilisé

Pour reprendre ton exemple :
xResult est numérique
xResult=xUn+xTauxTVA
xResult=xResult/100
xResult=xMoinsUn/xResult

Trace(xResult) //on obtient bien -15.384616

Donc, il est clair que ce n'est pas l'idéal de devoir faire du ligne à
ligne, mais c'est malheureusement logique et ca permet au moins de faire
du débug facilement:-)

Cordialement


--
Fabrice Harari
Consultant WinDev, WebDev et WinDev Mobile International

Disponible : WXShowroom.com, WXReplication (open source)
Bientôt : WXEDM (open source)
Plus d'information surhttp://fabriceharari.com



On 9/15/2015 8:29 AM, Alain Blanc wrote:
xTauxTVA est numérique = 5.5

// Chaque noeud de l'expression renvoie un Numérique :
Trace(dbgInfo(dbgNomType, TypeVar(xTauxTVA / 100)))
Trace(dbgInfo(dbgNomType, TypeVar(1 + xTauxTVA / 100)))
Trace(dbgInfo(dbgNomType, TypeVar(5 / (1 + xTauxTVA / 100))))

// En n'utilisant que des numériques à virgule flottante dans
l'expression on a le même problème :
xUn est numérique (*) = 1
xMoinsUn est numérique (*) = -1
xCent est numérique (*) = 100

Trace(xMoinsUn / (xUn + xTauxTVA / xCent))

// Même chose avec des littérales numériques :
>Trace(-0n1 / (0n1 + 0n5.5 / 0n100))
Signaler
0
0
#6
Membre enregistré
326 messages
Posté le 15 septembre 2015 - 17:03
Bonjour.

En monétaire ce problème n'existe pas et pourtant la précision sur la partie décimale est de 6 chiffres comme les numériques ! (voir lien de la doc).

Pour moi c'est un dysfonctionnement et sur ce point je ne suis pas d'accord avec Fabrice, le calcul doit se faire avec un maximum de précision et "l'arrondi" doit se faire uniquement à la fin !
En monétaire voilà les résultats.
4.739336
39.810427
0.985782
-0.947867

En numérique on devrait avoir exactement la même chose !

En réel en trace on a :
4.739336492891
39.81042654028
0.9857819905213
-0.9478672985782

Il y a un sacré "HIC" pour le type numérique; Je n'ai jamais utilisé le type numérique et à priori heureusement vu le résultat des calculs cela fait peur !

Michel.

http://doc.pcsoft.fr/fr-FR/?1514043&name=Details_sur_les_monetaires>
Signaler
0
0
#7
Posté le 15 septembre 2015 - 17:20
Fabrice : plutôt que faire de la théorie, j'ai préféré demander à WinDev ce qu'il me retourne avec TypeVar.

Les valeurs intermédiaires sont en type Numérique, c'est juste ce que dit le code, et du coup je ne comprends pas votre message.

xDénominateur est numérique(*) = (0n1+0n5.5/0n100)
soitxRésultat= -0n1
xRésultat=xRésultat/xDénominateur
Trace(xRésultat)
Trace(-0n1/xDénominateur)

Et là, quelle est l'explication selon vous ?

Pour moi, xDénominateur porte le problème, or c'est un numérique et ça ne contient rien d'autre.

>Merci encore pour votre attention, et merci de répondre si vous savez uniquement. (comme dans "Qui veut gagner des millions")
Signaler
0
0
#8
Posté le 15 septembre 2015 - 17:33
Je me suis un peu loupé sur le code, il manque un Trace(xDénominateur) pour montrer qu'il vaut bien 1.055.
Mais le code suivant sera bien plus parlant :

xDénominateur1 est numérique(*) = (0n1+0n5.5/0n100)
xDénominateur2 est numérique(*) = (1+5.5/100)
Trace(xDénominateur1)
Trace(xDénominateur2)
Trace(xDénominateur1=xDénominateur2?"égal"SINON"différent")
Trace(-0n1/xDénominateur1)
Trace(-0n1/xDénominateur2)


>Voilà, si quelqu'un arrive à m'expliquer ça, bravo et encore merci.
Signaler
0
0
#9
Membre enregistré
852 messages
Posté le 15 septembre 2015 - 18:13
Bonjour,
J'utilise des variables monétaires
moPrixht est unmonétaire
xTauxTVA est unmonétaire=5.5

moPrixht=5/ (1+ (xTauxTVA/100))

J'ai 4.739336

Ou des réels
Prixht est unréel
TauxTVA est unréel=5.5

Prixht=5/ (1+ (TauxTVA/100))

J'ai : 4.739336492891

Par contre si xTauxTVA est numérique, cela ne fonctionne pas.
Comme on dit : Ne pas mélanger les torchons avec les serviettes:)

J.Michel

--
Synchronize Systems International LTD
Développement d'outils de gestion

Environnements AS400 – Windows
Langages GAP III – CL – Visual Basic - Visual Adélia - Adélia - Windev
http://www.cashpower.fr/

>Bangkok / Pattaya
Signaler
0
0
#10
Posté le 15 septembre 2015 - 18:30
Bonjour

Pour quelques éclaircissements, voir la documentation sur les variables de type numérique,http://doc.pcsoft.fr/fr-FR/?1514072&name=Type_Numerique

Et notamment la rubrique Remarques :

Affectation d'un numérique
Lors de l'affectation d'un numérique par une valeur (valeur directement saisie, fournie par une fonction, ...), cette valeur est automatiquement convertie en réel par le compilateur.

Par exemple :
num1 est un numérique
num1=1234567890123456789123456789
Trace(num1)// num1 ne contient pas la bonne valeur

num2 est un numérique
num2=1234567890123456789.0
Trace(num2)// num2 ne contient pas la bonne valeur


Pour forcer l'affectation d'un numérique, utilisez 0n devant la valeur. Par exemple :

num1 est un numérique
num1=0n1234567890123456789123456789
Trace(num1)// num1 contient la bonne valeur

num2 est un numérique
num2=0n1234567890123456789.0
Trace(num2)// num2 contient la bonne valeur


Opération impliquant un numérique
Lors d'une opération impliquant une variable de type numérique, tous les calculs sont effectués au format des numériques manipulés.

En particulier, lors d'une opération entre un numérique et un réel, le réel est converti en numérique pour effectuer l'opération.

>Hemgé
Signaler
0
1
#11
Posté le 15 septembre 2015 - 23:26
Avez-vous essayé cela :
xTauxTVA est numérique=5.5
xPrixHT est numérique

xPrixHT=5./ (1.+xTauxTVA/100.)
Trace(xPrixHT)// affiche 4 au lieu de 4.739...
xPrixHT=42./ (1.+xTauxTVA/100.)
Trace(xPrixHT)// affiche 39 au lieu de 39.810...
xPrixHT=1.04/ (1.+xTauxTVA/100.)
Trace(xPrixHT)// affiche 3.8 au lieu de 3.829...
xPrixHT= -1./ (1.+xTauxTVA/100.)
Trace(xPrixHT)// affiche 79228162532711081675843436543 !
>
Signaler
0
0
#12
Posté le 16 septembre 2015 - 00:06
Bonjour,

Le code ci-dessous fonctionne et renvoie bien les bons résultats.

xTauxTVA est un numérique=5.5
xPrixHT est numérique
xPrixTTC est un numérique

xPrixTTC=5
xPrixHT=xPrixTTC/ (1+xTauxTVA/100)
Trace(xPrixHT)

xPrixTTC=42
xPrixHT=xPrixTTC/ (1+xTauxTVA/100)
Trace(xPrixHT)

xPrixTTC=1.04
xPrixHT=xPrixTTC/ (1+xTauxTVA/100)
Trace(xPrixHT)

xPrixTTC= -1
xPrixHT=xPrixTTC/ (1+xTauxTVA/100)
Trace(xPrixHT)


Je rejoint Fabrice sur son explication. En faisant directement "xPrixHT = 5 / (1 + xTauxTVA / 100)" le compilateur interprète le '5' comme un entier ou un reel, ce qui fausse le résultat final.

pour confirmation le code ci dessous redonne les résultats erronés

xTauxTVA est un numérique=5.5
xPrixHT est numérique
xPrixTTC est unentier

xPrixTTC=5
xPrixHT=xPrixTTC/ (1+xTauxTVA/100)
Trace(xPrixHT)

xPrixTTC=42
xPrixHT=xPrixTTC/ (1+xTauxTVA/100)
Trace(xPrixHT)

xPrixTTC=1.04
xPrixHT=xPrixTTC/ (1+xTauxTVA/100)
Trace(xPrixHT)

xPrixTTC= -1
xPrixHT=xPrixTTC/ (1+xTauxTVA/100)
Trace(xPrixHT)


La ligne suivante dans l'aide sur le type numerique est donc fausse, du moins dans le cas des divisions.

Opération impliquant un numérique
Lors d'une opération impliquant une variable de type numérique, tous les calculs sont effectués au format des numériques manipulés.

En particulier, lors d'une opération entre un numérique et un réel, le réel est converti en numérique pour effectuer l'opération.

En espérant que PC-Soft corrige dans la prochaine MAJ.

>Fred
Signaler
0
0
#13
Membre enregistré
962 messages
Posté le 16 septembre 2015 - 03:00
hello,
en faisant ceci :
xDénominateur1 est Variant= (0n1+0n5.5/0n100)
xDénominateur2 est Variant= (1+5.5/100)
Trace("xDénominateur1 : ",xDénominateur1," - type : ",xDénominateur1..Type)
Trace("xDénominateur2 : ",xDénominateur2," - type : ",xDénominateur2..Type)
Trace("wlNumérique : ",wlNumérique)
Trace("wlReel : ",wlRéel)


on obtient cela :
xDénominateur1:1.055-type:13
xDénominateur2:1.055-type:12
wlNumérique:13
wlReel:12


Les calculs se feraient-ils en variant (les plaisirs) ?

--
>Ami calmant, J.P
Signaler
0
0
#14
Posté le 16 septembre 2015 - 08:58
Bonjour à tous,

Je ne comprends pas tout :
- Hemgé : merci pour ce rappel, mais ça n'a pas de lien avec mon problème.
- Fred : le problème est quand il y a un "numérique (*)" à gauche et à droite de la division. C'est dans ce type que WinDev semble faire le cast implicitement.
- Jurassic Pork : je ne vois pas l'utilité des Variants, vous faites la même chose qu'avec TypeVar :

Mon test :
xTauxTVA est numérique=5.5
Trace(dbgInfo(dbgNomType,TypeVar(xTauxTVA/100)))
Trace(dbgInfo(dbgNomType,TypeVar(1+xTauxTVA/100)))
Trace(dbgInfo(dbgNomType,TypeVar(5/ (1+xTauxTVA/100))))


Test avec les variants :
xTauxTVA est numérique=5.5
exp1 est Variant=xTauxTVA/100
exp2 est Variant=1+xTauxTVA/100
exp3 est Variant=5/ (1+xTauxTVA/100)
Trace(dbgInfo(dbgNomType,exp1..Type))
Trace(dbgInfo(dbgNomType,exp2..Type))
Trace(dbgInfo(dbgNomType,exp3..Type))


>Même résultat, même conclusion : si une opérande est de type numérique, on obtient un numérique... et des résultats surprenants !
Signaler
1
0
#15
Posté le 16 septembre 2015 - 09:25
Le vrai problème des numériques est que :
- Le cast donne un "numérique (*)" (numérique à virgule flottante)
- Le "numérique (*)" ne s'adapte pas dynamiquement à la valeur, contrairement à ce qui est écrit dans la doc :

xVal1 est numérique(*) = -0n1.00000// crée un numérique avec 5 chiffres après la virgule (alors que la valeur ne le nécessite pas)
xVal2 est numérique(*) = -1.000000// crée un numérique sans chiffre après la virgule (pour le moment)

Trace(xVal1/ (1+0n5.5/100))// 4 chiffres après la virgule (pourquoi pas 5 voire plus ?)
Trace(xVal2/ (1+0n5.5/100))// overflow


Dans d'autres langages, les règles de propagation de la précision sont clairement établies :
https://msdn.microsoft.com/en-us/library/ms190476.aspx

>Mais dans le cas de "numérique (*)", ça devrait être "simple" a priori : il suffit de s'inspirer des réels (IEEE 754) et faire la même chose en décimal.
Signaler
0
0
#16
Membre enregistré
218 messages
Posté le 16 septembre 2015 - 10:02
J'ai rencontré le même problème par le passé, avec Webdev. Je l'avais résolu en stockant le taux de TVA, non dans un numérique, mais dans un réel. Cette solution, mise en place il y a déjà quelques années, n'a cessé de donner le bon résultat (et d'être nécessaire) d'une version à l'autre : c'est pourquoi je doute que ce comportement soit corrigé un jour.

Ainsi, la séquence :

rTauxTVA est unréel=5.5
rRésultat1 est unréel=5/(1+rTauxTVA/100)
xRésultat2 est un numérique=5/(1+rTauxTVA/100)
moRésultat3 est unmonétaire=5/(1+rTauxTVA/100)
Trace("rRésulat1="+rRésultat1)
Trace("xRésultat2="+xRésultat2)
Trace("moRésultat3="+moRésultat3)


... nous donne :

rRésulat1=4.739336492891
xRésultat2=4.739336
moRésultat3=4.739336


Alors que si le taux de TVA est un numérique, on obtient :

rRésulat1=4
xRésulat2=4
moRésulat3=4


>S'il est en monétaire, les 3 calculs donnent 4.739336
Signaler
0
0
#17
Posté le 16 septembre 2015 - 11:20
Personnellement, je pense que ce comportement doit être corrigé, car personne ne souhaite de telles erreurs dans ses calculs.
Il ne s'agit pas ici d'une erreur de précision normale et prédictible, mais bien d'un bug dans le maintien des paramètres de précision de la variable. (doublé d'un joli overflow)

>Si on est plusieurs à signaler le bug au Support Technique, ils devraient enregistrer une fiche incident, et il est probable que WD21 bénéficie du correctif.
Signaler
0
0
#18
Posté le 16 septembre 2015 - 13:14
Bonjour,

Encore une petite contribution.

//Dans un bouton
num1 est un numérique
num1=123456789012345.67890123456789
//Info("123456789012345.67890123456789" + CRLF + num1 + " / " + TypeVar(num))

num2 est un numérique
num2=1234567890123456789.0
//Info("1234567890123456789.0" + CRLF + num2 + " / " + TypeVar(num2))

num3 est un numérique
num3=0n123456789012345.6789017654321
//Info("0n123456789012345.67890123456789" + CRLF + num3 + " / " + TypeVar(num3))

xTauxTVA est numérique(2,10) =0n5.5
xMontant est un numérique(2,10) =0n5
xUn est un numérique(2,10) =0n1
xCent est un numérique(2,10) =0n100

xRés1 est un numérique=xTauxTVA/100
xRés2 est un numérique=1+xTauxTVA/100
xRés3 est un numérique=xMontant/ (xUn+xTauxTVA/xCent)

xRés4 est un numérique(2,10) =xMontant/ (xUn+xTauxTVA/xCent)
xRés5 est un numérique(2,2) =xMontant/ (xUn+xTauxTVA/xCent)
xRés6 est un numérique(2,2) =Arrondi(xMontant/ (xUn+xTauxTVA/xCent),2)

Info("num1 - traité comme réel"+CRLF+"123456789012345.67890123456789"+CRLF+num1+CRLF+CRLF+...
"num2 - traité comme réel, mais puissance 10 conservée"+CRLF+"1234567890123456789.0"+CRLF+num2+CRLF+CRLF+...
"num3 - traité comme numérique avec décimales auto et sans arrondi"+CRLF+"0n123456789012345.6789016789017654321"+CRLF+num3+CRLF+CRLF+...
xTauxTVA+CRLF+xRés1+CRLF+xRés2+CRLF+"Rés3 - 6 déc.auto : "+xRés3+CRLF+"Rés4 - 10 déc. : "+xRés4+CRLF+"Rés5 - tronqué : "+xRés5+CRLF+"Rés6 - arrondi : "+xRés6)


Num1
Affectation d’un numérique par une valeur sans préfixer par 0n et sans chiffre significatif après le séparateur décimal : cette valeur est automatiquement convertie en réel par le compilateur et donc arrondie au 15e chiffre significatif

Num2
Affectation d’un numérique par une valeur sans préfixer par 0n et avec des chiffres significatifs après le séparateur décimal : cette valeur est automatiquement convertie en réel par le compilateur et donc arrondie au 15e chiffre significatif, mais la puissance 10 initiale est conservée en ‘boostant’ le réel obtenu par l’ajout de 4 ‘0’ (zéros) à droite et on ‘restaure’ ainsi le nombre initial de chiffres précédant le séparateur décimal !!!

Num3
Affectation d’un numérique par une valeur en préfixant par 0n et avec des chiffres significatifs après le séparateur décimal.
La valeur affectée est conservée et tronquée (pas arrondie) au 6e rang, nombre automatique de décimales sauf déclaration explicite.

Les calculs (Résultats 4 - 5 -6) permettent de constater que si TOUS les opérandes sont des numériques correctement déclarés ET affectés (càd avec le préfixe 0n), tout fonctionne comme il se doit (mais à quel prix !).

Les résultats sont tronqués et non arrondis selon le format affecté à la variable recevant le résultat.
Reste à explorer les éventuelles variations en fonction du type d’opération, soulevées par le test de Chris.

>Hemgé
Signaler
0
0
#19
Posté le 17 septembre 2015 - 11:56
Bonjour,

Je suis d'accord avec ceux qui disent qu'il ne faut simplement pas utiliser ce type.
Surtout qu'il utilise la troncation au lieu de l'arrondi comme le monétaire.

Mais mon problème c'est qu'il y a le risque de l'utiliser accidentellement car :
- Pour définir un décimal avec n'importe quelle précision dans l'analyse (pour SQL Server par exemple), il faut utiliser ce type
- Du coup, les champs de type numérique héritent de ce type
- Puis les opérations impliquant directement ces champs ou rubriques vont hériter aussi de ce type
- Enfin, ce type va être prioritaire sur tous les autres dans les opérations arithmétiques

Bref, il faudrait presque une option de projet pour désactiver ce type dangereux pour nos données.
Dans notre cas, on s'est retrouvés avec des chiffres délirants dans la base de données, et c'est une chance, car des chiffres juste mal arrondis auraient été détectés bien plus (trop) tard.

>Ca m'inquiète, tous nos projets sont susceptibles d'avoir des bugs gravissimes à cause du type numérique.
Signaler
0
0
#20
Membre enregistré
352 messages
Posté le 18 septembre 2015 - 12:29
en remplaçant "numérique" par "réel", les résultats sont ok
Signaler
0
0
#21
Posté le 18 septembre 2015 - 17:53
Le problème des réels c'est qu'ils sont en binaire, et pas en décimal. Par exemple 0.1 n'existe pas dans le type réel, ce n'est qu'une approximation.

Pour de la gestion (surtout comptable et financière), on préfère utiliser du décimal, donc les types monétaire et numérique.
Ces types doivent se comporter comme des opérations posées à la main.

Le réel est très précis, mais il sera plus adapté à de la physique, du graphisme, etc.

Un autre intérêt des types décimaux à précision fixe est de pouvoir définir un arrondi automatique.
Par exemple, je travaille en euros avec 2 chiffres après la virgule et tous mes résultats intermédiaires sont arrondis à des centimes, et non à des fractions de centimes.
Problème : les monétaires sont forcément à 6 chiffres après la virgule, et les numériques font de la troncation... Du coup aucun des deux n'est adapté à mon exemple !

Tout ceci n'est pas très rassurant...

Espérons que ça soit amélioré en version 21 : je vais moi aussi envoyer une demande via l'outil "Requête au Support Technique", et j'espère que d'autres le feront.

Voici où le trouver :



>
Signaler
0
0
→ Revenir à WINDEV 2025