norme calculs comptables en C ?
Le
machin chose
Salut,
Je cherche (probablement mal) s'il existe une norme pour
faire les calculs & arrondis comptables en programmation ?
Je sais que ce n'est pas une question spécifique au C, mais
comme c'est avec ça que je travaille, je suis ouvert a toute
url ou fu2.
Le contexte est un logiciel de facturation maison interfacé
avec une base postgresql sous unix (freebsd): jusqu'a maintenant
je me débrouillais en réalisant tous mes calculs avec des euros
arrondis sur les centiemes; mais postgresql ne fait pas les
mêmes arrondis et lors de vérifications croisées, ils me
ressort parfois des erreurs, sur lesquelles, il a entierement
raison.. En fait, j'avais envi au départ de poser cette
question sous la forme "faut il proscrire les floats/double
quand on fait de la compta en C ?"
Merci d'avoir lu jusque là ;-) P.
Je cherche (probablement mal) s'il existe une norme pour
faire les calculs & arrondis comptables en programmation ?
Je sais que ce n'est pas une question spécifique au C, mais
comme c'est avec ça que je travaille, je suis ouvert a toute
url ou fu2.
Le contexte est un logiciel de facturation maison interfacé
avec une base postgresql sous unix (freebsd): jusqu'a maintenant
je me débrouillais en réalisant tous mes calculs avec des euros
arrondis sur les centiemes; mais postgresql ne fait pas les
mêmes arrondis et lors de vérifications croisées, ils me
ressort parfois des erreurs, sur lesquelles, il a entierement
raison.. En fait, j'avais envi au départ de poser cette
question sous la forme "faut il proscrire les floats/double
quand on fait de la compta en C ?"
Merci d'avoir lu jusque là ;-) P.
Poser une question
En float/double seuls les quantités qui sont des puissances (ou des
sommes finies de puissances) positives ou négatives de 2 sont exactes :
les variables de ce type sont donc à proscrire en comptabilité.
A ma connaissance (un peu vieille il est vrai), les calculs comptables
sont réalisés en nombres entiers de centimes : pour les additions et
soustractions ca ne pose pas de problème.
Pour les calculs d'intérêts c'est un peu plus sioux et la règle
d'arrondi qu'on m'avait indiquée était d'arrondir à l'entier pair le
plus proche, sans qu'on m'explique pourquoi.
Si un entier classique n'est pas assez grand pour manipuler des
milliards de milliards d'euros, il est possible de mettre en oeuvre des
bibliothèques d'arithmétique à précision infinie (enfin limitée par
la taille de la mémoire de votre machine quand même).
--
Cordialement
Dominique MICOLLET Email : enlevez le .fr.fr
Universite de Bourgogne
9, Avenue Alain SAVARY BP 47870 Tel : +33/(0)3-80-39-59-27
21078 DIJON CEDEX FRANCE Tfx : +33/(0)3-80-39-68-69
en règle générale, et quelque soit le langage, si tu veux parler de nombre
décimaux (comprendre cette classe de nombre bizares qui sont exacts dans
leur écriture décimale) il est fortement déconseillé de travailler avec des
flottants.
Je ne sais pas si il y a souvent des divisions en compta. à ma connaissance,
les opérations de compta sont des divisions clippées (comprendre tronquées,
ou dans les cas `compliqués' arrondies au centime près).
Il me parait judicieux de choisir comme représentation d'une somme d'argent
comme sa valeur en centimes. Tu te ramènes alors à du calcul sur des
entiers.
(Bien sur, si tu travailles dans la banque, ou des trucs où les Euros ont 4
ou 6 chiffres après la virgule il vaut mieux representer les sommes
d'argent par leur valeur en 1/10^6 eme d'euro).
bref, tout faire pour éviter le flottant qui :
1/ est plus lent que le calcul entier
2/ fait des approximations immondes
3/ ne fera pas toujours ce que tu veux, et surtout te rend la vie folle, vu
que par exemple, tu ne peux plus décement faire de test à 0.
--
·O· Pierre Habouzit
··O
OOO http://www.madism.org
En programmation, je ne sais. Sinon il existe des choses, par exemple dans
le monde de la comptabilité.
En gros, il faut travailler en centimes (ou un sous-multiple); le seul
problème sont les arrondis (quand intervient un taux quelconque, que ce soit
des intérêts, de la TVA ou un prorata temporis), et c'est là qu'au niveau
des normes on trouve de tout, en général selon ce qui arrange celui qui
rédige la norme.
D'abord, le plus général c'est d'arrondir au centime le plus proche (mais on
trouve des variantes ;-)). Ce qui laisse ouvert le cas où le millime, le
troisième chiffre après la virgule, est un 5. Dans ce cas, tout est ouvert :
le plus répandus sont soit toujours au-dessus, soit au centime pair le plus
proche (arrondi dit du banquier en France).
Non, effectivement.
La réponse aurait été oui.
Antoine
Sauf si on utilise une bibliotheque appropriee:
http://lipforge.ens-lyon.fr/www/crlibm/
a+, ld.
Faire quand même gaffe a l'amplitude des nombres considérés : avec des centimes,
on est limité à 20 millions d'euros pour les résultats, et bien moins en
pratique quand on calcule des intérêtes eux-mêmes exprimés en points de base
(100emes de pourcentages), voire plus encore de précision pour des taux
journaliers.
On peut avoir recours à l'arithmétique 64 bits, les long long font au moins 64
bits, mais cela limite la portabilité du programme. En revanche l'amplitude
devrait suffire pour les valeurs intermédiaires dans les calculs : on peut
encore calculer les taux d'intérêt à 6 chiffres sur plus de 100 milliards
d'euros.
Une alternative est d'utiliser des nombres entiers stockés dans des doubles qui
représentent des nombres de centimes et de faire les calculs en rationnels :
S = somme en centimes
T = 3.81% d'intérêts
I = round(S * 381 / 10000) -> intérêts sur 1 prêt d'un an remboursé in fine.
C'est faux sur les processeurs actuels.
En fait elles sont parfaitement définies, mais pas forcément compatibles avec
les contraintes comptables.
C'est pas le pire, mais c'est vrai que c'est très chiant à prendre en compte
partout.
En C# ils ont inventé le type decimal pour gérer exactement ce type de problème.
Tu peux sans doute trouver des libs utilisables en C avec une approche
similaire, cherche decimal ou bcd.
Chqrlie.