Discussion :

[BasicZX81]

Bonjour à tous,
J'ai cherché partout l'information j'ai un peu de mal à savoir quel type de variables je dois utiliser pour faire des calculs financiers.
Autant cela me parait évident pour les valeurs en Euros, ça l'ai beaucoup moins pour les valeurs fractionnaires.
Cela concernent les variables dans mon programme mais aussi les types de champs dans ma base Access.

Exemple pour le calcul de la marge en % = Marge en Euros/PV) :
------------------------------------------------------------------
Désignation | Valeur | Variable VB.NET | Variable Access
------------------------------------------------------------------
Prix de Revient | 900.00 € | Décimal | DataTypeEnum.adCurrency
Prix de Vente | 950.00 € | Décimal | DataTypeEnum.adCurrency
Marge | 50.00 € | Décimal | DataTypeEnum.adCurrency
Marge en % | 0.0526... | ??????? | ????????
------------------------------------------------------------------

je ne sais pas si l'exemple est bien choisi mais le but est d'éviter les erreurs d'arrondies.
Merci beaucoup si vous pouvez me conseiller.

[plume13]

Hello,
Le mieux c'est de ne pas stocker la marge étant donné qu'elle se calcule depuis le prix d'achat et le prix de vente. Comme cela tu n'auras pas de problème d'arrondis.

[BasicZX81]

Bonjour et merci de me répondre.
C'est une idée en effet. Je vais malgré tout stocker la marge, juste pour pouvoir l'afficher mais j'éviterais de réutiliser cette valeur dans mes calculs comme ça je n'ai plus de problème.
Presque au hasard je dirais , je vais utiliser les singles dans le code et l'équivalent en Access : (type DataTypeEnum.adSingle).

Je marque résolu, mais si quelqu'un a une autre suggestion qu'il n'hésite pas.

[DonQuiche]

En principe les calculs financiers se font avec "decimal" (19 28 chiffres significatifs). Mais ça c'est pour de vrais calculs financiers. S'il ne s'agit que d'afficher un résultat à l'utilisateur ou de faire un peu de compatibilité, single (7 chiffres significatifs) ou double (15 chiffres significatifs) suffisent amplement. Avec 7 chiffres significatifs tu fais sans problème tes additions au centime d'euro près pour des sommes inférieures à 100k€.

Enfin attention à ne pas confondre les problèmes de représentation avec des problèmes d'arrondis. Par exemple 1/10 ne peut pas être représenté en binaire avec un nombre fini de bits significatifs (tout comme 1/3 ne peut pas l'être en décimal - ils sont irrationnels). Ceci n'est pas une erreur d'arrondi qui se résoudrait en augmentant la précision mais quelque chose qui se traite par un formatage adéquat de l'affichage, ou en optant pour le type decimal qui est exprimé en base 10.


EDIT: correction. Les 19 chiffres significatifs précédemment mentionnés correspondent en fait aux nombres sur 80 bits qui n'ont pas de mot clé associé sous dotnet.

[BasicZX81]

Bonjour et merci de me répondre.
J'ai décoché résolu parce que ce qui me parraissait evident l'est de moins en moins . (Je ferais des essais sur mon PC de devellopement dès ce soir mais pour le moment je suis dans le flou complet concernant le type decimal et Currency (Access))
Je dit peut-être une bétise et mais il me semble que le type Decimal (et Currency) arrondi à 2 chiffres aprés la virgule et je peux me retrouver avec le cas suivant :

Si j'ai un prix de câble égale à 15€ le kilométre et que je stocke le prix au métre dans une variable décimale ou dans un champ Currency (Access), je risque d'arrondir le prix au métre à 0.01€ et donc avec une précision insuffisante dans ce cas. le prix réel etant de 0.015€.

Dans ce cas faut'il définir au cas par cas les types de variable selon la maniere dont ils interviennent dans le calcul ? Je me demande aussi si la variable Decimal correspond bien au type Currency.
Je commence à être un peu perdu.

[DonQuiche]

Avant toute chose je tiens à préciser que je n'ai aucune compétence concernant Access, mon unique expérience avec ce dernier se résumant à une après-midi d'initiation il y a plus de quinze ans.

Cela étant dit, sur dotnet le type decimal est un type en virgule flottante et il n'y a donc aucune histoire d'arrondi automatique à deux chiffres après la virgule. Sa principale spécificité est le fait qu'il est exprimé sous la forme a*10^b au lieu du a*2^b des autres types réels, ce qui évite les problèmes de représentativité dans certaines applications. Qui plus est il a une grande précision (128 bits contre 64 pour double et 32 pour single) et l'essentiel de ces 128 bits sont utilisés pour la mantisse, au détriment de l'exposant, si bien que l'intervalle couvert va environ de ±1E28 à ±1E-28.

Maintenant, concernant Access, Google m'a renvoyé cette page. Single et Double correspondent à leurs équivalents C# mais Currency est un type spécifique à Access avec un fonctionnement différent des autres types puisqu'il est en virgule fixe. Très vraisemblablement c'est un entier en 64 bits représentant des dix-millièmes d'unité, ce qui évite les problèmes de représentativité (sur la page que j'ai donnée il est défini comme contenant 15 chiffres avant la virgule, et 4 après, or 2^64 = 1.8E19).

Du coup, si les problèmes de représentativité sont importants (et ils le sont sans doute), opte simplement pour decimal côté c# et currency côté Access. Sinon choisis de chaque côté en fonction du nombre de chiffres significatifs dont tu as besoin, quitte à doubler la précision du côté (C# ou Access) où tu as des calculs élaborés à faire, ou si tu ne sais pas s'ils sont élaborés (méthode grossière mais qui évite d'avoir à se plonger dans les arcanes du calcul numérique).


EDIT : Grosse édition importante, liée au fait que decimal et currency évitent les problèmes de représentativité, et au fait que j'ai pigé ce qu'est vraiment currency.