Discussion :

[oumay]

bonjour à tous,
je cherche comment déclarer une variable monétaire de forme par exemple: 1,500,820.000
dans la base de données mysql et dans mon code en c# sachant que je vais appliquer des opérations de soustraction, addition et division sur cette variable

(par exemple dans le code je vas appliquer l'opération d'addition : 1,500,820.000 + 80.000 = 1,500,900.000)

merci d'avance pour l'aide.

[jopopmk]

Salut,

tu prends le problème à l'envers.
Tu dois manipuler des float normaux, et uniquement au moment de l'affichage tu les mets au format que tu souhaites.

Bon dev.

[oumay]

merci pour la réponse
donc je déclare ma variable en tant que float normal (exemple 1500820,2) et lors de l'affichage devient 1,500,820.200

[jopopmk]

merci pour la réponse
donc je déclare ma variable en tant que float normal (exemple 1500820,2) et lors de l'affichage devient 1,500,820.200

Tu utilises un float (ou un double), et quand t'as besoin de l'afficher tu utilises la fonction ToString() avec le format qui va bien, exemple :

Code :

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

1
2
3
double d = 1500820.2;
MessageBox.Show(d.ToString("#,##0.00", CultureInfo.CreateSpecificCulture("en-US")));
// affiche "1,500,820.20"

[François DORIN]

Bonjour,

tu prends le problème à l'envers.

Loin de là. Il a des contraintes sur les nombres. Comme ce sont des valeurs monétaires, l'arrondi n'est généralement pas toléré.

Tu dois manipuler des float normaux, et uniquement au moment de l'affichage tu les mets au format que tu souhaites.

Non, il ne doit pas justement. Il faut qu'il se pose les bonnes questions. Est-ce que les erreurs d'arrondi sont tolérables ou pas ? Si oui, les nombres flottant peuvent être utilisées. Si non, il faut se tourner vers une solution plus robuste.
Tu peux alors utiliser le type decimal en C# (qui est mieux recommandé pour les calculs financiers). Niveau base de données, MySQL dispose aussi d'un type decimal de mémoire...

[jopopmk]

C'est comme le calcul scientifique, on fait les arrondis (selon convention) à la fin du bal. De plus c'est pas parce que le centime est la plus petite unité de factiure qu'elle est la plus petite unité d'un prix de vente. Enfin, s'il est amené à faire de la conversion de devise, ça va faire des dégâts. Perso j'ai fait quelques appli manipulant du sousou (compta, paie, facturation, finance), j'ai toujours travaillé avec double et même en base on mettait une précision à 10^-5 mini.

Maintenant à lui de voir son besoin, perso je partirais pas sur de la précision à 10^-2 forcée.

[François DORIN]

Maintenant à lui de voir son besoin, perso je partirais pas sur de la précision à 10^-2 forcée.

Le type decimal n'est pas limité à 10^-2 en terme de précision. En C#, il peut aller jusqu'à 10^-28. Et niveau base de données, on définit généralement la précision souhaitée.

j'ai toujours travaillé avec double

Et un jour, il faudra trouver pourquoi il y a une différence de 3 centimes...

[Pol63]

double ne stocke pas un nombre mais ce qu'il a de plus proche ^^

l'exemple est simple :

Code :

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

1
2
double d = 80.74;
d = d * 100;

là tu penses que d vaut 8074 alors qu'il vaut 8073.9999999999991

certes la décimale qui change est loin, mais manipules quelques dizaines de milliers de nombre et la différence avec la réalité va s'agrandir

decimal lui stocke la vraie valeur

[jopopmk]

Et un jour, il faudra trouver pourquoi il y a une différence de 3 centimes...

Ça m'est jamais arrivé, je "croise du bois" ^^
Toutefois, si les conventions d'arrondi sont définies ça n'arrivera pas, ou alors ce sera by design.

@Pol : je sais comment fonctionne un float , par contre decimal n'a pas de limite ?
Je vais abuser un peu mais vous auriez pas un lien vers la source SVP ?

edit : j'ai trouvé ça en me baladant sur le site filé par DotNetMatt.

[Pol63]

pas lu ton lien, mais un single/double ca doit être une fraction avec un multiplicateur (puissance de 2), enfin c'est un encodage mathématique (wikipedia doit avoir l'info)
alors qu'un decimal c'est un entier avec une position de virgule

single/double n'ont pas que des inconvénients, ils sont plus rapide pour les calculs

mais je confirme que sur un jeu de données volumineux des centimes ca arrive (ou grammes ou autre)
surtout avec des totaux ou des moyennes

[StringBuilder]

C'est comme le calcul scientifique, on fait les arrondis (selon convention) à la fin du bal.

Totalement faux.

Si t'as des Kiwi, des Pêches et des Pommes à 3,49 € le kilo, si t'en prends 700g de chaque, tu paies :

arrondi(3.49 * 0.7) + arrondi(3.49 * 0.7) + arrondi(3.49 * 0.7) = 2.44 + 2.44 + 2.44 = 7.32 €

Et non :

arrondi(3.49 * 0.7 + 3.49 * 0.7 + 3.49 * 0.7) = 7.33 €

L'arrondi se fait bien au fur et à mesure quand on travaille en monétaire !

Et le type FLOAT est absolument à éviter, car même en faisant 1 + 1 au final t'es pas certain d'avoir 2 mais plutôt 1.99 ou 2.01 ce qui est totalement incohérent pour du monétaire.

Edit : Un moyen simple et performant pour travailler en monétaire, c'est de travailler avec des INT, en prenant soin de multiplier les prix par 100 et de les rediviser au moment de l'affichage.
=> En effet, sans gestion des décimaux, tous les arrondis intermédiaires seront faits pour toi.