déclaration de variable float

Version imprimable

12/05/2017, 07h50
oumay

déclaration de variable float

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.
12/05/2017, 08h12
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.
12/05/2017, 11h54
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
12/05/2017, 12h10
jopopmk
Citation:

Envoyé par 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

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:

1 2 3 double d = 1500820.2; MessageBox.Show(d.ToString("#,##0.00", CultureInfo.CreateSpecificCulture("en-US"))); // affiche "1,500,820.20"
12/05/2017, 15h12
François DORIN

Bonjour,

Citation:

Envoyé par jopopmk

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é.

Citation:

Envoyé par jopopmk

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...
12/05/2017, 15h39
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.
12/05/2017, 15h44
François DORIN

Citation:

Envoyé par jopopmk

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.

Citation:

Envoyé par jopopmk

j'ai toujours travaillé avec double

Et un jour, il faudra trouver pourquoi il y a une différence de 3 centimes... :aie:
12/05/2017, 16h19
Pol63
double ne stocke pas un nombre mais ce qu'il a de plus proche ^^

l'exemple est simple :
Code:

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
12/05/2017, 20h19
jopopmk

Citation:

Envoyé par François DORIN

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

Ç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 :oops:, 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.
12/05/2017, 22h17
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
14/05/2017, 09h12
StringBuilder

Citation:

Envoyé par jopopmk

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.