|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Débuté par Alain Blanc, 15 sep. 2015 12:46 - 20 réponses |
| |
| | | |
|
| |
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)
xPrixHT = 42 / (1 + xTauxTVA / 100)
Trace(xPrixHT)
xPrixHT = 1.04 / (1 + xTauxTVA / 100)
Trace(xPrixHT)
xPrixHT = -1 / (1 + xTauxTVA / 100)
Trace(xPrixHT)
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. |
| |
| |
| | | |
|
| | |
| |
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 sur http://fabriceharari.com
On 9/15/2015 4:46 AM, Alain Blanc wrote:
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)
xPrixHT = 42 / (1 + xTauxTVA / 100)
Trace(xPrixHT)
xPrixHT = 1.04 / (1 + xTauxTVA / 100)
Trace(xPrixHT)
xPrixHT = -1 / (1 + xTauxTVA / 100)
Trace(xPrixHT) 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. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
940 messages
Popularité : +66 (68 votes) |
|
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)
xPrixHT = 5 / (1 + ( xTauxTVA / 100))
Trace(xPrixHT)
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 !! 
Bon dèv |
| |
| |
| | | |
|
| | |
| |
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
Trace(dbgInfo(dbgNomType, TypeVar(xTauxTVA / 100)))
Trace(dbgInfo(dbgNomType, TypeVar(1 + xTauxTVA / 100)))
Trace(dbgInfo(dbgNomType, TypeVar(5 / (1 + xTauxTVA / 100))))
xUnest numérique (*) = 1
xMoinsUnest numérique (*) = -1
xCentest numérique (*) = 100
Trace(xMoinsUn / (xUn + xTauxTVA / xCent))
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. |
| |
| |
| | | |
|
| | |
| |
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 sur http://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)) |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
326 messages
Popularité : +15 (19 votes) |
|
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 |
| |
| |
| | | |
|
| | |
| |
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)
soit xRé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") |
| |
| |
| | | |
|
| | |
| |
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. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
834 messages
Popularité : +13 (13 votes) |
|
Posté le 15 septembre 2015 - 18:13 |
Bonjour,
J'utilise des variables monétaires
moPrixht est un monétaire
xTauxTVA est un monétaire = 5.5
moPrixht = 5 / (1 + (xTauxTVA / 100))
J'ai 4.739336
Ou des réels
Prixht est un réel
TauxTVA est un ré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 |
| |
| |
| | | |
|
| | |
| |
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)
num2 est un numérique
num2 = 1234567890123456789.0
Trace(num2)
Pour forcer l'affectation d'un numérique, utilisez 0n devant la valeur. Par exemple :
num1 est un numérique
num1 = 0n1234567890123456789123456789
Trace(num1)
num2 est un numérique
num2 = 0n1234567890123456789.0
Trace(num2)
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é |
| |
| |
| | | |
|
| | |
| |
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)
xPrixHT = 42. / (1. + xTauxTVA / 100.)
Trace(xPrixHT)
xPrixHT = 1.04 / (1. + xTauxTVA / 100.)
Trace(xPrixHT)
xPrixHT = -1. / (1. + xTauxTVA / 100.)
Trace(xPrixHT) |
| |
| |
| | | |
|
| | |
| |
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 un entier
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 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
962 messages
Popularité : +183 (185 votes) |
|
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 |
| |
| |
| | | |
|
| | |
| |
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 ! |
| |
| |
| | | |
|
| | |
| |
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
xVal2 est numérique (*) = -1.000000
Trace(xVal1 / (1 + 0n5.5 / 100))
Trace(xVal2 / (1 + 0n5.5 / 100))
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. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
218 messages
Popularité : +8 (8 votes) |
|
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 un réel = 5.5
rRésultat1 est un réel = 5/(1+rTauxTVA/100)
xRésultat2 est un numérique = 5/(1+rTauxTVA/100)
moRésultat3 est un moné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 |
| |
| |
| | | |
|
| | |
| |
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. |
| |
| |
| | | |
|
| | |
| |
Posté le 16 septembre 2015 - 13:14 |
Bonjour,
Encore une petite contribution.
num1 est un numérique
num1 = 123456789012345.67890123456789
num2 est un numérique
num2 = 1234567890123456789.0
num3 est un numérique
num3 = 0n123456789012345.6789017654321
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é |
| |
| |
| | | |
|
| | |
| |
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. |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
352 messages
Popularité : +12 (18 votes) |
|
Posté le 18 septembre 2015 - 12:29 |
en remplaçant "numérique" par "réel", les résultats sont ok |
| |
| |
| | | |
|
| | |
| |
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 :
|
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|