On est hors sujet mais je continue un peu : il me paraît évident (depuis de nombreuses années, donc avant de programmer en C) que les applications de comptabilité ne doivent pas manipuler les montants en utilisant directement les types flottants, parce que les chiffres décimaux après la virgule n'ont pas de représentation unique.
Pour avoir enseigné un peu d'informatique de gestion, programmée essentiellement en COBOL, je peux confirmer que l'unité est le centime et non l'euro (ou plutôt le franc à l'époque). D'ailleurs les calculatrices comptables avaient (ont ?) une touche "00" permettant d'entrer un nombre "entier" 5,00 => "5" "00". C'est bien de la virgule fixe, plus simple à mettre en oeuvre au niveau des processeurs. C'est la procédure d'affichage qui se débrouille pour remettre la virgule au bon endroit.
À propos de calcul de TVA, pour moi la TVA est toujours en centimes (même si la manière d'arrondir peut être l'objet de discussions «intéressantes» avec le fisc...) Par contre, la formule HT + TVA != TTC peut apparaître quand tu dois recalculer le montant HT à partir du TTC: il est des fois où cela ne tombe pas juste !
Le problème de la TVA et d'un certain nombre d'autres taxes est effectivement lié aux arrondis, car les taux ne fournissent pas des portions centimes : il faut ruser pour les récupérer ou les cacher. Et pour autant que je sache, ils se calculent sur le montant TTC.
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia mentionne un "arrondi bancaire" sans expliquer son intérêt.
Cordialement
Dominique.
Antoine Leca a écrit :
On est hors sujet mais je continue un peu : il me paraît évident (depuis
de nombreuses années, donc avant de programmer en C) que les
applications de comptabilité ne doivent pas manipuler les montants en
utilisant directement les types flottants, parce que les chiffres
décimaux après la virgule n'ont pas de représentation unique.
Pour avoir enseigné un peu d'informatique de gestion, programmée
essentiellement en COBOL, je peux confirmer que l'unité est le centime et
non l'euro (ou plutôt le franc à l'époque).
D'ailleurs les calculatrices comptables avaient (ont ?) une touche "00"
permettant d'entrer un nombre "entier" 5,00 => "5" "00".
C'est bien de la virgule fixe, plus simple à mettre en oeuvre au niveau des
processeurs. C'est la procédure d'affichage qui se débrouille pour remettre
la virgule au bon endroit.
À propos de calcul de TVA, pour moi la TVA est toujours en centimes
(même si la manière d'arrondir peut être l'objet de discussions
«intéressantes» avec le fisc...) Par contre, la formule HT + TVA != TTC
peut apparaître quand tu dois recalculer le montant HT à partir du TTC:
il est des fois où cela ne tombe pas juste !
Le problème de la TVA et d'un certain nombre d'autres taxes est
effectivement lié aux arrondis, car les taux ne fournissent pas des portions
centimes : il faut ruser pour les récupérer ou les cacher. Et pour autant
que je sache, ils se calculent sur le montant TTC.
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia
mentionne un "arrondi bancaire" sans expliquer son intérêt.
On est hors sujet mais je continue un peu : il me paraît évident (depuis de nombreuses années, donc avant de programmer en C) que les applications de comptabilité ne doivent pas manipuler les montants en utilisant directement les types flottants, parce que les chiffres décimaux après la virgule n'ont pas de représentation unique.
Pour avoir enseigné un peu d'informatique de gestion, programmée essentiellement en COBOL, je peux confirmer que l'unité est le centime et non l'euro (ou plutôt le franc à l'époque). D'ailleurs les calculatrices comptables avaient (ont ?) une touche "00" permettant d'entrer un nombre "entier" 5,00 => "5" "00". C'est bien de la virgule fixe, plus simple à mettre en oeuvre au niveau des processeurs. C'est la procédure d'affichage qui se débrouille pour remettre la virgule au bon endroit.
À propos de calcul de TVA, pour moi la TVA est toujours en centimes (même si la manière d'arrondir peut être l'objet de discussions «intéressantes» avec le fisc...) Par contre, la formule HT + TVA != TTC peut apparaître quand tu dois recalculer le montant HT à partir du TTC: il est des fois où cela ne tombe pas juste !
Le problème de la TVA et d'un certain nombre d'autres taxes est effectivement lié aux arrondis, car les taux ne fournissent pas des portions centimes : il faut ruser pour les récupérer ou les cacher. Et pour autant que je sache, ils se calculent sur le montant TTC.
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia mentionne un "arrondi bancaire" sans expliquer son intérêt.
Cordialement
Dominique.
Dominique MICOLLET
Dominique MICOLLET a écrit :
Un truc illisible :
effectivement lié aux arrondis, car les taux ne fournissent pas des portions centimes : il faut ruser pour les récupérer ou les cacher. Et
... car les taux fournissent des portions de centimes ....
Dominique MICOLLET a écrit :
Un truc illisible :
effectivement lié aux arrondis, car les taux ne fournissent pas des
portions centimes : il faut ruser pour les récupérer ou les cacher. Et
... car les taux fournissent des portions de centimes ....
À ce que je suppose, l'intérêt est d'arrondir une fois sur deux vers le haut et une fois sur deux vers le bas, ce qui fait qu'en moyenne les biais auront plus de chances de se compenser que de s'accumuler.
Je suppose aussi qu'il reviendrait au même d'arrondir toujours vers le chiffre impair plutôt que toujours vers le chiffre pair.
Cordialement, -- Olivier Miakinen
Le 17/10/2012 12:43, Dominique MICOLLET a écrit :
Wikipedia mentionne un "arrondi bancaire" sans expliquer son intérêt.
À ce que je suppose, l'intérêt est d'arrondir une fois sur deux vers le
haut et une fois sur deux vers le bas, ce qui fait qu'en moyenne les
biais auront plus de chances de se compenser que de s'accumuler.
Je suppose aussi qu'il reviendrait au même d'arrondir toujours vers le
chiffre impair plutôt que toujours vers le chiffre pair.
À ce que je suppose, l'intérêt est d'arrondir une fois sur deux vers le haut et une fois sur deux vers le bas, ce qui fait qu'en moyenne les biais auront plus de chances de se compenser que de s'accumuler.
Je suppose aussi qu'il reviendrait au même d'arrondir toujours vers le chiffre impair plutôt que toujours vers le chiffre pair.
Cordialement, -- Olivier Miakinen
Samuel DEVULDER
Le 17/10/2012 12:43, Dominique MICOLLET a écrit :
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia mentionne un "arrondi bancaire" sans expliquer son intérêt.
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus proche (round to even):
1.5 est arrondi à 2 2.5 est arrondi à 2 3.5 est arrondi à 4
-1.5 est arrondi à -2 -2.5 est arrondi à -2 -3.5 est arrondi à -4
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les opérations "arrondies" les unes aux autres. C'est le mode d'arrondi par défaut dans IEEE754 d'après la wikipedia.
sam.
Le 17/10/2012 12:43, Dominique MICOLLET a écrit :
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia
mentionne un "arrondi bancaire" sans expliquer son intérêt.
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus
proche (round to even):
1.5 est arrondi à 2
2.5 est arrondi à 2
3.5 est arrondi à 4
-1.5 est arrondi à -2
-2.5 est arrondi à -2
-3.5 est arrondi à -4
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les
opérations "arrondies" les unes aux autres. C'est le mode d'arrondi par
défaut dans IEEE754 d'après la wikipedia.
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia mentionne un "arrondi bancaire" sans expliquer son intérêt.
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus proche (round to even):
1.5 est arrondi à 2 2.5 est arrondi à 2 3.5 est arrondi à 4
-1.5 est arrondi à -2 -2.5 est arrondi à -2 -3.5 est arrondi à -4
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les opérations "arrondies" les unes aux autres. C'est le mode d'arrondi par défaut dans IEEE754 d'après la wikipedia.
sam.
Antoine Leca
Samuel DEVULDER écrivit :
Le 17/10/2012 12:43, Dominique MICOLLET a écrit :
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia mentionne un "arrondi bancaire" sans expliquer son intérêt.
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus proche (round to even):
... uniquement dans le cas de strict égalité de distance.
1.5 est arrondi à 2 2.5 est arrondi à 2 3.5 est arrondi à 4
1.51 arrondi à 2 2.51 arrondi à 3 2.50000000000000000000000000000000000000000000000000000001 arrondi à 3
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les opérations "arrondies" les unes aux autres.
Je ne crois que le souci soient les enchaînements, mais plutôt le biais systématique pour la valeur .500000_0_ (et seulement elle), biais qui est vers le haut¹ si on arrondi de manière habituelle (par défaut pour la première décimale entre 0 et 4, par excès pour la première décimale entre 5 et 9).
Antoine __________ ¹: en fait, le biais est vers l'infini, ou encore "away of zero".
Samuel DEVULDER écrivit :
Le 17/10/2012 12:43, Dominique MICOLLET a écrit :
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia
mentionne un "arrondi bancaire" sans expliquer son intérêt.
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus
proche (round to even):
... uniquement dans le cas de strict égalité de distance.
1.5 est arrondi à 2
2.5 est arrondi à 2
3.5 est arrondi à 4
1.51 arrondi à 2
2.51 arrondi à 3
2.50000000000000000000000000000000000000000000000000000001 arrondi à 3
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les
opérations "arrondies" les unes aux autres.
Je ne crois que le souci soient les enchaînements, mais plutôt le biais
systématique pour la valeur .500000_0_ (et seulement elle), biais qui
est vers le haut¹ si on arrondi de manière habituelle (par défaut pour
la première décimale entre 0 et 4, par excès pour la première décimale
entre 5 et 9).
Antoine
__________
¹: en fait, le biais est vers l'infini, ou encore "away of zero".
Je serais curieux de connaitre la règle d'arrondi du fisc. Wikipedia mentionne un "arrondi bancaire" sans expliquer son intérêt.
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus proche (round to even):
... uniquement dans le cas de strict égalité de distance.
1.5 est arrondi à 2 2.5 est arrondi à 2 3.5 est arrondi à 4
1.51 arrondi à 2 2.51 arrondi à 3 2.50000000000000000000000000000000000000000000000000000001 arrondi à 3
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les opérations "arrondies" les unes aux autres.
Je ne crois que le souci soient les enchaînements, mais plutôt le biais systématique pour la valeur .500000_0_ (et seulement elle), biais qui est vers le haut¹ si on arrondi de manière habituelle (par défaut pour la première décimale entre 0 et 4, par excès pour la première décimale entre 5 et 9).
Antoine __________ ¹: en fait, le biais est vers l'infini, ou encore "away of zero".
Samuel DEVULDER
Le 18/10/2012 19:28, Antoine Leca a écrit :
Samuel DEVULDER écrivit :
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus proche (round to even):
... uniquement dans le cas de strict égalité de distance.
Oui j'avais oublié de le préciser. Sans cela on a un sacré biais: le résultat est pair dans 100% des cas!
1.5 est arrondi à 2 2.5 est arrondi à 2 3.5 est arrondi à 4
1.51 arrondi à 2 2.51 arrondi à 3
Oui. Ce sont des arrondis au plus proche.
2.50000000000000000000000000000000000000000000000000000001 arrondi à 3
Dans l'esprit oui. Il est plus proche de 3 que de 2. Cependant ce nombre n'est pas représentable en double ou float. Du coup son représentant le plus proche: 2.5000000000000000 sera lui arrondi à 2.
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les opérations "arrondies" les unes aux autres.
Je ne crois que le souci soient les enchaînements, mais plutôt le biais systématique pour la valeur .500000_0_ (et seulement elle), biais qui
en effet.
est vers le haut¹ si on arrondi de manière habituelle (par défaut pour la première décimale entre 0 et 4, par excès pour la première décimale entre 5 et 9).
Il a aussi d'autres propriétés. Comme il est symétrique par rapport à 0, il commute avec la négation: arrondi(-x) = -arrondi(x). Je crois aussi qu'il préserve la moyenne pour des distributions suffisamment éloignées de 0: moyenne(arrondi(x1), arrondi(x2), ...) = moyenne(x1, x2, ...). J'imagine que cela doit être lié à l'absence de biais qui ne s'accumule pas dans la sommation nécessaire à la moyenne.
Merci pour toutes les précisions,
sam.
Le 18/10/2012 19:28, Antoine Leca a écrit :
Samuel DEVULDER écrivit :
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus
proche (round to even):
... uniquement dans le cas de strict égalité de distance.
Oui j'avais oublié de le préciser. Sans cela on a un sacré biais: le
résultat est pair dans 100% des cas!
1.5 est arrondi à 2
2.5 est arrondi à 2
3.5 est arrondi à 4
1.51 arrondi à 2
2.51 arrondi à 3
Oui. Ce sont des arrondis au plus proche.
2.50000000000000000000000000000000000000000000000000000001 arrondi à 3
Dans l'esprit oui. Il est plus proche de 3 que de 2. Cependant ce nombre
n'est pas représentable en double ou float. Du coup son représentant le
plus proche: 2.5000000000000000 sera lui arrondi à 2.
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les
opérations "arrondies" les unes aux autres.
Je ne crois que le souci soient les enchaînements, mais plutôt le biais
systématique pour la valeur .500000_0_ (et seulement elle), biais qui
en effet.
est vers le haut¹ si on arrondi de manière habituelle (par défaut pour
la première décimale entre 0 et 4, par excès pour la première décimale
entre 5 et 9).
Il a aussi d'autres propriétés. Comme il est symétrique par rapport à 0,
il commute avec la négation: arrondi(-x) = -arrondi(x). Je crois aussi
qu'il préserve la moyenne pour des distributions suffisamment éloignées
de 0: moyenne(arrondi(x1), arrondi(x2), ...) = moyenne(x1, x2, ...).
J'imagine que cela doit être lié à l'absence de biais qui ne s'accumule
pas dans la sommation nécessaire à la moyenne.
Je crois que l'arrondi du banquier est arrondir à l'entier pair le plus proche (round to even):
... uniquement dans le cas de strict égalité de distance.
Oui j'avais oublié de le préciser. Sans cela on a un sacré biais: le résultat est pair dans 100% des cas!
1.5 est arrondi à 2 2.5 est arrondi à 2 3.5 est arrondi à 4
1.51 arrondi à 2 2.51 arrondi à 3
Oui. Ce sont des arrondis au plus proche.
2.50000000000000000000000000000000000000000000000000000001 arrondi à 3
Dans l'esprit oui. Il est plus proche de 3 que de 2. Cependant ce nombre n'est pas représentable en double ou float. Du coup son représentant le plus proche: 2.5000000000000000 sera lui arrondi à 2.
L’intérêt est que cela limite les biais d'arrondis quand on enchaine les opérations "arrondies" les unes aux autres.
Je ne crois que le souci soient les enchaînements, mais plutôt le biais systématique pour la valeur .500000_0_ (et seulement elle), biais qui
en effet.
est vers le haut¹ si on arrondi de manière habituelle (par défaut pour la première décimale entre 0 et 4, par excès pour la première décimale entre 5 et 9).
Il a aussi d'autres propriétés. Comme il est symétrique par rapport à 0, il commute avec la négation: arrondi(-x) = -arrondi(x). Je crois aussi qu'il préserve la moyenne pour des distributions suffisamment éloignées de 0: moyenne(arrondi(x1), arrondi(x2), ...) = moyenne(x1, x2, ...). J'imagine que cela doit être lié à l'absence de biais qui ne s'accumule pas dans la sommation nécessaire à la moyenne.
