norme calculs comptables en C ?

Dominique.Micollet

25/08/2005 à 16:11

In article <430dce0e$0$18557$,
machin chose writes:

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.

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

Pierre Habouzit

25/08/2005 à 16:15

machin chose wrote:

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.

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

machin chose wrote:

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.

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 madcoder@debian.org
OOO http://www.madism.org

Vous avez filtré cet utilisateur ! Consultez son message

machin chose wrote:

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.

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

Antoine Leca

25/08/2005 à 16:45

En <news:430dce0e$0$18557$,

Je cherche (probablement mal) s'il existe une norme pour
faire les calculs & arrondis comptables en programmation ?

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

Je sais que ce n'est pas une question spécifique au C,

Non, effectivement.

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 ?"

La réponse aurait été oui.

Antoine

Laurent Deniau

25/08/2005 à 17:21

Antoine Leca wrote:

En <news:430dce0e$0$18557$,

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 ?"

La réponse aurait été oui.

Sauf si on utilise une bibliotheque appropriee:

http://lipforge.ens-lyon.fr/www/crlibm/

a+, ld.

Charlie Gordon

27/08/2005 à 14:04

"Pierre Habouzit" wrote in message
news:430dd28e$0$2948$

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

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.

bref, tout faire pour éviter le flottant qui :
1/ est plus lent que le calcul entier

C'est faux sur les processeurs actuels.

2/ fait des approximations immondes

En fait elles sont parfaitement définies, mais pas forcément compatibles avec
les contraintes comptables.

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.

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.

"Pierre Habouzit" <madcoder@debian.org> wrote in message
news:430dd28e$0$2948$626a14ce@news.free.fr...

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

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.

bref, tout faire pour éviter le flottant qui :
1/ est plus lent que le calcul entier

C'est faux sur les processeurs actuels.

2/ fait des approximations immondes

En fait elles sont parfaitement définies, mais pas forcément compatibles avec
les contraintes comptables.

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.

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.

Vous avez filtré cet utilisateur ! Consultez son message

"Pierre Habouzit" wrote in message
news:430dd28e$0$2948$

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

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.

bref, tout faire pour éviter le flottant qui :
1/ est plus lent que le calcul entier

C'est faux sur les processeurs actuels.

2/ fait des approximations immondes

En fait elles sont parfaitement définies, mais pas forcément compatibles avec
les contraintes comptables.

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.

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.

Jean-Marc Bourguet

29/08/2005 à 11:23

machin chose writes:

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 ?"

Il y a deux problemes potentiel ici.

Le premier est un probleme de compta sur les arrondis. Il faut savoir
ce qu'on veut et ne pas demander l'impossible (comme par exemple que
sur une facture on indique le montant de la TVA avec chaque item --
montant arrondi -- et qu'ensuite en faisant la somme on arrive au meme
resultat qu'en calculant la TVA sur la somme des items ayant le meme
taux).

Le deuxieme probleme est l'utilisation de type flottants en
comptabilite. A priori c'est une mauvaise idee: l'objectif des types
flottants est d'avoir une precision relative constante sur un
intervalle assez large. En comptabilite on cherche a avoir une
precision absolue et quand il faut arrondir on defini les regles de
maniere precise (par exemple en specifiant que sur une facture il faut
faire la somme de la TVA sur chaque item plutot que calculer la TVA
sur la somme -- je ne sais pas si c'est le cas ou non, c'est pas mon
domaine de competance mais si ce n'est pas le cas je me demande
comment la pratique d'afficher les prix TVA comprise peut
fonctionner). Comme l'arrondi desire est a ma connaissance toujours
base sur une representation decimale et que les flottants sont
generalement base sur une representation binaire, il y a peut de
chance pour que les arrondis soient corrects. Meme avec des flottants
decimaux, il faudrait pas mal de chance pour que l'arrondi corresponde
aux exigences comptables, surtout quand on sait qu'arrondir deux fois
(une fois par l'implementation des flottants, une fois par le
programmeur qui suit les normes comptables) n'est pas la meme chose
qu'arrondir une fois suivant la seconde methode. Donc a ma
connaissance en comptabilite on manipule des entiers (eventuellement
avec une precision multiple) et on fait les arrondis correctement a la
main. Ce qui est peut-etre possible, c'est d'utiliser les double
comme etant des entiers sur 53 bits (utiliser les floats comme etant
des entiers sur 24 bits a peu d'interet).

A+

--
Jean-Marc

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

machin chose <nowhere@naoned.bzh> writes:

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 ?"

Il y a deux problemes potentiel ici.

Le premier est un probleme de compta sur les arrondis. Il faut savoir
ce qu'on veut et ne pas demander l'impossible (comme par exemple que
sur une facture on indique le montant de la TVA avec chaque item --
montant arrondi -- et qu'ensuite en faisant la somme on arrive au meme
resultat qu'en calculant la TVA sur la somme des items ayant le meme
taux).

Le deuxieme probleme est l'utilisation de type flottants en
comptabilite. A priori c'est une mauvaise idee: l'objectif des types
flottants est d'avoir une precision relative constante sur un
intervalle assez large. En comptabilite on cherche a avoir une
precision absolue et quand il faut arrondir on defini les regles de
maniere precise (par exemple en specifiant que sur une facture il faut
faire la somme de la TVA sur chaque item plutot que calculer la TVA
sur la somme -- je ne sais pas si c'est le cas ou non, c'est pas mon
domaine de competance mais si ce n'est pas le cas je me demande
comment la pratique d'afficher les prix TVA comprise peut
fonctionner). Comme l'arrondi desire est a ma connaissance toujours
base sur une representation decimale et que les flottants sont
generalement base sur une representation binaire, il y a peut de
chance pour que les arrondis soient corrects. Meme avec des flottants
decimaux, il faudrait pas mal de chance pour que l'arrondi corresponde
aux exigences comptables, surtout quand on sait qu'arrondir deux fois
(une fois par l'implementation des flottants, une fois par le
programmeur qui suit les normes comptables) n'est pas la meme chose
qu'arrondir une fois suivant la seconde methode. Donc a ma
connaissance en comptabilite on manipule des entiers (eventuellement
avec une precision multiple) et on fait les arrondis correctement a la
main. Ce qui est peut-etre possible, c'est d'utiliser les double
comme etant des entiers sur 53 bits (utiliser les floats comme etant
des entiers sur 24 bits a peu d'interet).

A+

--
Jean-Marc

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Vous avez filtré cet utilisateur ! Consultez son message

machin chose writes:

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 ?"

Il y a deux problemes potentiel ici.

Le premier est un probleme de compta sur les arrondis. Il faut savoir
ce qu'on veut et ne pas demander l'impossible (comme par exemple que
sur une facture on indique le montant de la TVA avec chaque item --
montant arrondi -- et qu'ensuite en faisant la somme on arrive au meme
resultat qu'en calculant la TVA sur la somme des items ayant le meme
taux).

Le deuxieme probleme est l'utilisation de type flottants en
comptabilite. A priori c'est une mauvaise idee: l'objectif des types
flottants est d'avoir une precision relative constante sur un
intervalle assez large. En comptabilite on cherche a avoir une
precision absolue et quand il faut arrondir on defini les regles de
maniere precise (par exemple en specifiant que sur une facture il faut
faire la somme de la TVA sur chaque item plutot que calculer la TVA
sur la somme -- je ne sais pas si c'est le cas ou non, c'est pas mon
domaine de competance mais si ce n'est pas le cas je me demande
comment la pratique d'afficher les prix TVA comprise peut
fonctionner). Comme l'arrondi desire est a ma connaissance toujours
base sur une representation decimale et que les flottants sont
generalement base sur une representation binaire, il y a peut de
chance pour que les arrondis soient corrects. Meme avec des flottants
decimaux, il faudrait pas mal de chance pour que l'arrondi corresponde
aux exigences comptables, surtout quand on sait qu'arrondir deux fois
(une fois par l'implementation des flottants, une fois par le
programmeur qui suit les normes comptables) n'est pas la meme chose
qu'arrondir une fois suivant la seconde methode. Donc a ma
connaissance en comptabilite on manipule des entiers (eventuellement
avec une precision multiple) et on fait les arrondis correctement a la
main. Ce qui est peut-etre possible, c'est d'utiliser les double
comme etant des entiers sur 53 bits (utiliser les floats comme etant
des entiers sur 24 bits a peu d'interet).

A+

--
Jean-Marc

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet

29/08/2005 à 11:31

Laurent Deniau writes:

Antoine Leca wrote:
En <news:430dce0e$0$18557$,

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 ?"
La réponse aurait été oui.

Sauf si on utilise une bibliotheque appropriee:

http://lipforge.ens-lyon.fr/www/crlibm/

Je ne vois pas en quoi ca aide. La seule maniere d'utiliser des
flottants binaires -- c'est ce qu'a l'air d'offrir cette bibliotheque
-- en compta, c'est de n'utiliser que les entiers qui y sont
representables exactement (sauf peut-etre dans des problemes
actuariels). Meme des flottants decimaux ne doivent pas aider
beaucoup -- on sait tous les deux les problemes que posent un double
arrondi.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

machin chose

29/08/2005 à 13:56

machin chose writes:

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 ?"

Il y a deux problemes potentiel ici.

Le premier est un probleme de compta sur les arrondis. Il faut savoir
ce qu'on veut et ne pas demander l'impossible (comme par exemple que
sur une facture on indique le montant de la TVA avec chaque item --
montant arrondi -- et qu'ensuite en faisant la somme on arrive au meme
resultat qu'en calculant la TVA sur la somme des items ayant le meme
taux).
je comprend bien ce que tu veux dire, mais dans mon idée, c'est la

moindre des choses que deux totaux "croisés" (entendre provenant de
deux modes de calculs différents) soient identiques. C'était un peu
le l'idée premiere derriere ma question originale.

Pour ce qui est de l'utilisation des float ou double, mon idée était
déjà un peu faite en réalité mais l'avis de personnes ayant
l'expérience m'interresse pas mal.
Travailler sur des ints ne me pose aucun problème métaphysique. (ou sur
des long long, un jour j'espère: quand j'éditerais des factures en
millions d'euros ;-).

Merci donc a tous pour vos réponses.

P.

Antoine Leca

29/08/2005 à 16:02

En news:4312f7ef$0$18593$,

je comprend bien ce que tu veux dire, mais dans mon idée, c'est la
moindre des choses que deux totaux "croisés" (entendre provenant de
deux modes de calculs différents) soient identiques.

C'est vrai pour l'arithmétique des matheux (les nombres rationnels, un truc
noté avec un Q, si cela te rappelle des cours de mathématiques).

Ce n'est vrai, ni en informatique, ni en comptabilité.

Toujours pour rester en mathématiques, peut-être te souviens-tu avoir
entendu dire que Z (les entiers relatifs) n'était pas un « corps ». Et bien,
tu viens de toucher du doigt pourquoi ce n'en est pas un : effectivement,
les deux modes de calcul ne sont pas identiques.

La comptabilité utilise une arithmétique fondamentalement liée aux entiers
relatifs, avec un facteur de conversion (les montants en centimes sont bien
des entiers); un problème complémentaire en comptabilité informatique est
celui des limites de l'espace représenté (milions d'euros, milliard d'euros
? quid si on doit manipuler plusierus monnaies, donc s'il faut avoir plus de
décimales sur les quantités élémentaires).

Les float et les doubles ne sont pas facilement assimilables à l'un des
ensembles mathématiques ci-dessus, ce qui fait qu'ils posent encore plus de
problème avec leurs propriétés arithmétiques (plutôt, l'absence de certaines
d'entre elles). Une vision réductrice est de les limiter aux entiers qu'ils
peuvent représenter, ce qui donne 24 bits (environ 16 millions, 160.000¤ en
centimes) pour les float, ce qui semble clairement insuffisant, et 53 bits
(8 millions de milliards... de centimes) pour les double IEEE; comme les
double sont plus répandus que les entiers 64 bits (long long), et les
calculs légèrement plus rapides, ce peut être un choix possible, mais
attention à bien définir les propriétés d'arrondi (particulièrement avec les
nombres négatifs ou quand on approche de 0,00).

Antoine

norme calculs comptables en C ?

9 réponses

Veuillez sélectionner un problème