Existe t-il (dans la STL ou autre) une possibilité de stocker (définir
le nombre de chiffres avant et après la virgule) et de gérer
(addition, soustraction, affichage, ...) des nombres monétaires.
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote in message news:<40162f7d$0$22329$...
[...]
Le C++ de Borland (la VCL) utilise un classe Currency. Je ne cite Borland que parce que ça donne une base de réflexion, en particulier sur le fait qu'un int32 comme un float64 sont insuffisants. La donnée encapsulée est un int64, lui-même issu d'un type Delphi natif, qui semble utiliser la CPU dans les calculs (le type Currency de Delphi est classé parmi les types réels).
(J'aimerais bien voir un type qui n'utilise pas la CPU dans les calculs:-).)
Les erreurs d'arrondi sont minimisées.
Ce n'est pas dit. Mais ce n'est pas ce qu'on veut. Ce qu'il faut, c'est que les erreurs d'arrondi (inévitables) correspondent à celles exigeaient par la législation.
Ce qui est intéressant, ce sont les étendues (ils ont du y réfléchir): - entier signé sur 64 bits. - les quatre chiffres les moins significatifs de la représentation décimale sont considérés comme "après la virgule".
La législation sur l'Euro exige que les calculs se font avec cinque chiffres après le décimal, avec le résultat final arrondi à deux chiffres.
- ainsi, la représentation va de : -922337203685477.5808 à 922337203685477.5807 L'écriture des opérateurs dépend de ce dont vous disposez en int64 et de votre niveau de portabilité, mais ce n'est pas la mer à boire, sauf celui qui affiche la somme en bon français si vous en avez besoin.
Je pense que la plus petite subdivision "légale" de l'euro est le millime, et non le centime (comme pour le franc), indépendamment de la précision interne dont le but est d'éviter les erreurs d'arrondi.
Tout dépend de ce que tu fais. En ce qui concerne le calcul de la TVA, par exemple, le fisc ne le veut qu'à l'Euro près.
PS: J'ai lu que la CPU Intel optimise les calculs financiers exacts. Mais je ne retrouve pas la citation, et même s'il s'agit du format packed BCD ou de flottant 80 bits.
Le CPU Intel a des instructions pour la « correction BCD ». Il faut toujours écrire la boucle de base, en traitant un octet à la fois.
Le CPU des gros IBM, en revanche, a bien des instructions machine pour les quatres opérateurs de base sur des BCD de 8 octets (16 chiffres décimaux). Ainsi que des instructions de décalage de 4 en 4 sur 8 octets. Quand j'ai dû implémenter les quatres opérations sur un BCD virgule flottant de 13 chiffres décimaux, il m'a fallu environ 2 mille lignes de C. L'équivalent en assembleur Intel n'en était pas loin (mais plus rapide). L'équivalent en assembleur IBM 390, c'était moins d'une centaine de lignes. Et beaucoup, beaucoup plus rapide.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote
in message news:<40162f7d$0$22329$626a54ce@news.free.fr>...
[...]
Le C++ de Borland (la VCL) utilise un classe Currency. Je ne cite
Borland que parce que ça donne une base de réflexion, en particulier
sur le fait qu'un int32 comme un float64 sont insuffisants. La donnée
encapsulée est un int64, lui-même issu d'un type Delphi natif, qui
semble utiliser la CPU dans les calculs (le type Currency de Delphi
est classé parmi les types réels).
(J'aimerais bien voir un type qui n'utilise pas la CPU dans les
calculs:-).)
Les erreurs d'arrondi sont minimisées.
Ce n'est pas dit. Mais ce n'est pas ce qu'on veut. Ce qu'il faut, c'est
que les erreurs d'arrondi (inévitables) correspondent à celles
exigeaient par la législation.
Ce qui est intéressant, ce sont les étendues (ils ont du y réfléchir):
- entier signé sur 64 bits.
- les quatre chiffres les moins significatifs de la représentation
décimale sont considérés comme "après la virgule".
La législation sur l'Euro exige que les calculs se font avec cinque
chiffres après le décimal, avec le résultat final arrondi à deux
chiffres.
- ainsi, la représentation va de :
-922337203685477.5808 à 922337203685477.5807
L'écriture des opérateurs dépend de ce dont vous disposez en int64 et
de votre niveau de portabilité, mais ce n'est pas la mer à boire, sauf
celui qui affiche la somme en bon français si vous en avez besoin.
Je pense que la plus petite subdivision "légale" de l'euro est le
millime, et non le centime (comme pour le franc), indépendamment de la
précision interne dont le but est d'éviter les erreurs d'arrondi.
Tout dépend de ce que tu fais. En ce qui concerne le calcul de la TVA,
par exemple, le fisc ne le veut qu'à l'Euro près.
PS: J'ai lu que la CPU Intel optimise les calculs financiers exacts.
Mais je ne retrouve pas la citation, et même s'il s'agit du format
packed BCD ou de flottant 80 bits.
Le CPU Intel a des instructions pour la « correction BCD ». Il faut
toujours écrire la boucle de base, en traitant un octet à la fois.
Le CPU des gros IBM, en revanche, a bien des instructions machine pour
les quatres opérateurs de base sur des BCD de 8 octets (16 chiffres
décimaux). Ainsi que des instructions de décalage de 4 en 4 sur 8
octets. Quand j'ai dû implémenter les quatres opérations sur un BCD
virgule flottant de 13 chiffres décimaux, il m'a fallu environ 2 mille
lignes de C. L'équivalent en assembleur Intel n'en était pas loin (mais
plus rapide). L'équivalent en assembleur IBM 390, c'était moins d'une
centaine de lignes. Et beaucoup, beaucoup plus rapide.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote in message news:<40162f7d$0$22329$...
[...]
Le C++ de Borland (la VCL) utilise un classe Currency. Je ne cite Borland que parce que ça donne une base de réflexion, en particulier sur le fait qu'un int32 comme un float64 sont insuffisants. La donnée encapsulée est un int64, lui-même issu d'un type Delphi natif, qui semble utiliser la CPU dans les calculs (le type Currency de Delphi est classé parmi les types réels).
(J'aimerais bien voir un type qui n'utilise pas la CPU dans les calculs:-).)
Les erreurs d'arrondi sont minimisées.
Ce n'est pas dit. Mais ce n'est pas ce qu'on veut. Ce qu'il faut, c'est que les erreurs d'arrondi (inévitables) correspondent à celles exigeaient par la législation.
Ce qui est intéressant, ce sont les étendues (ils ont du y réfléchir): - entier signé sur 64 bits. - les quatre chiffres les moins significatifs de la représentation décimale sont considérés comme "après la virgule".
La législation sur l'Euro exige que les calculs se font avec cinque chiffres après le décimal, avec le résultat final arrondi à deux chiffres.
- ainsi, la représentation va de : -922337203685477.5808 à 922337203685477.5807 L'écriture des opérateurs dépend de ce dont vous disposez en int64 et de votre niveau de portabilité, mais ce n'est pas la mer à boire, sauf celui qui affiche la somme en bon français si vous en avez besoin.
Je pense que la plus petite subdivision "légale" de l'euro est le millime, et non le centime (comme pour le franc), indépendamment de la précision interne dont le but est d'éviter les erreurs d'arrondi.
Tout dépend de ce que tu fais. En ce qui concerne le calcul de la TVA, par exemple, le fisc ne le veut qu'à l'Euro près.
PS: J'ai lu que la CPU Intel optimise les calculs financiers exacts. Mais je ne retrouve pas la citation, et même s'il s'agit du format packed BCD ou de flottant 80 bits.
Le CPU Intel a des instructions pour la « correction BCD ». Il faut toujours écrire la boucle de base, en traitant un octet à la fois.
Le CPU des gros IBM, en revanche, a bien des instructions machine pour les quatres opérateurs de base sur des BCD de 8 octets (16 chiffres décimaux). Ainsi que des instructions de décalage de 4 en 4 sur 8 octets. Quand j'ai dû implémenter les quatres opérations sur un BCD virgule flottant de 13 chiffres décimaux, il m'a fallu environ 2 mille lignes de C. L'équivalent en assembleur Intel n'en était pas loin (mais plus rapide). L'équivalent en assembleur IBM 390, c'était moins d'une centaine de lignes. Et beaucoup, beaucoup plus rapide.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
sebastien.plipon
Merci pour toutes vos réponses.
Je ne connaissait pas les "GNU MP", mais mon besoin étant assez simple (souvent 2 chiffres après la virgule, mais parfois plus : 6,55957) je pense que je vais faire ma propre classe.
Cdlt.
Merci pour toutes vos réponses.
Je ne connaissait pas les "GNU MP", mais mon besoin étant assez simple
(souvent 2 chiffres après la virgule, mais parfois plus : 6,55957) je
pense que je vais faire ma propre classe.
Je ne connaissait pas les "GNU MP", mais mon besoin étant assez simple (souvent 2 chiffres après la virgule, mais parfois plus : 6,55957) je pense que je vais faire ma propre classe.
Cdlt.
Pierre Maurette
a écrit dans le message de news:
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote in message news:<40162f7d$0$22329$...
[...]
Le C++ de Borland (la VCL) utilise un classe Currency. Je ne cite Borland que parce que ça donne une base de réflexion, en particulier sur le fait qu'un int32 comme un float64 sont insuffisants. La donnée encapsulée est un int64, lui-même issu d'un type Delphi natif, qui semble utiliser la CPU dans les calculs (le type Currency de Delphi est classé parmi les types réels).
(J'aimerais bien voir un type qui n'utilise pas la CPU dans les calculs:-).) Bon, faute de frappe ... FPU, bien sur ...
Pierre
<kanze@gabi-soft.fr> a écrit dans le message de news:
d6652001.0401270945.5dc7438b@posting.google.com...
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote
in message news:<40162f7d$0$22329$626a54ce@news.free.fr>...
[...]
Le C++ de Borland (la VCL) utilise un classe Currency. Je ne cite
Borland que parce que ça donne une base de réflexion, en particulier
sur le fait qu'un int32 comme un float64 sont insuffisants. La donnée
encapsulée est un int64, lui-même issu d'un type Delphi natif, qui
semble utiliser la CPU dans les calculs (le type Currency de Delphi
est classé parmi les types réels).
(J'aimerais bien voir un type qui n'utilise pas la CPU dans les
calculs:-).)
Bon, faute de frappe ... FPU, bien sur ...
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote in message news:<40162f7d$0$22329$...
[...]
Le C++ de Borland (la VCL) utilise un classe Currency. Je ne cite Borland que parce que ça donne une base de réflexion, en particulier sur le fait qu'un int32 comme un float64 sont insuffisants. La donnée encapsulée est un int64, lui-même issu d'un type Delphi natif, qui semble utiliser la CPU dans les calculs (le type Currency de Delphi est classé parmi les types réels).
(J'aimerais bien voir un type qui n'utilise pas la CPU dans les calculs:-).) Bon, faute de frappe ... FPU, bien sur ...
Pierre
Samuel Krempp
le Tuesday 27 January 2004 18:45, écrivit :
La législation sur l'Euro exige que les calculs se font avec cinque chiffres après le décimal, avec le résultat final arrondi à deux chiffres.
et la loi arrive à formuler une contrainte sur la façon de faire les calculs permettant de s'assurer que ces 5 chiffres seront au final suffisant ?? par exemple est-ce qu'une banque pourrait décider de faire les calculs d'interêt en sommant des interêts par intervalle de temps très court afin d'avoir un gros décalage sur la somme finale ? ah mais en fait pour éviter ça il suffit d'obliger que toute imprécision de calcul soit en défaveur de celui qui fait le calcul, j'imagine.
il y a des matheux qui sont chargés de vérifier ça qque part ?
-- Sam
le Tuesday 27 January 2004 18:45, kanze@gabi-soft.fr écrivit :
La législation sur l'Euro exige que les calculs se font avec cinque
chiffres après le décimal, avec le résultat final arrondi à deux
chiffres.
et la loi arrive à formuler une contrainte sur la façon de faire les calculs
permettant de s'assurer que ces 5 chiffres seront au final suffisant ??
par exemple est-ce qu'une banque pourrait décider de faire les calculs
d'interêt en sommant des interêts par intervalle de temps très court afin
d'avoir un gros décalage sur la somme finale ?
ah mais en fait pour éviter ça il suffit d'obliger que toute imprécision de
calcul soit en défaveur de celui qui fait le calcul, j'imagine.
il y a des matheux qui sont chargés de vérifier ça qque part ?
La législation sur l'Euro exige que les calculs se font avec cinque chiffres après le décimal, avec le résultat final arrondi à deux chiffres.
et la loi arrive à formuler une contrainte sur la façon de faire les calculs permettant de s'assurer que ces 5 chiffres seront au final suffisant ?? par exemple est-ce qu'une banque pourrait décider de faire les calculs d'interêt en sommant des interêts par intervalle de temps très court afin d'avoir un gros décalage sur la somme finale ? ah mais en fait pour éviter ça il suffit d'obliger que toute imprécision de calcul soit en défaveur de celui qui fait le calcul, j'imagine.
il y a des matheux qui sont chargés de vérifier ça qque part ?
-- Sam
James Kanze
Samuel Krempp writes:
|> le Tuesday 27 January 2004 18:45, écrivit :
|> > La législation sur l'Euro exige que les calculs se font avec |> > cinque chiffres après le décimal, avec le résultat final |> > arrondi à deux chiffres.
|> et la loi arrive à formuler une contrainte sur la façon de |> faire les calculs permettant de s'assurer que ces 5 chiffres seront |> au final suffisant ??
Qu'il suffisse ou non, c'est (au moins pour certains calculs) la loi.
|> par exemple est-ce qu'une banque pourrait décider de faire les |> calculs d'interêt en sommant des interêts par intervalle de |> temps très court afin d'avoir un gros décalage sur la somme |> finale ?
Comment la somme se fait, et sur quoi on arrondit, et bien précisé. Donc, par exemple, si tu as une facture avec beaucoup de petites postes en francs, la loi exige que la somme se fait sur les francs, et que la conversion en Euro se fait une fois, à la fin.
En ce qui concerne la TVA, c'est plus compilqué, dans la mésure que les prix affichés de chaque article le comprend déjà. N'empêche que le montant que doit payer le commerçant, ce n'est pas la somme des TVA de chaque article, mais la TVA sur la somme des prix hors-taxe.
|> ah mais en fait pour éviter ça il suffit d'obliger que toute |> imprécision de calcul soit en défaveur de celui qui fait le |> calcul, j'imagine.
La loi est très précise sur la façon que doit se faire le calcul, et qui que ce soit qui le fait doit forcément retrouver le même résultat.
|> il y a des matheux qui sont chargés de vérifier ça qque |> part ?
Est-ce que la loi est enforcée, tu veux dire ? Je ne sais pas -- systèmatiquement, sûrement pas, mais s'il y a un contrôle fiscal...
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:
|> le Tuesday 27 January 2004 18:45, kanze@gabi-soft.fr écrivit :
|> > La législation sur l'Euro exige que les calculs se font avec
|> > cinque chiffres après le décimal, avec le résultat final
|> > arrondi à deux chiffres.
|> et la loi arrive à formuler une contrainte sur la façon de
|> faire les calculs permettant de s'assurer que ces 5 chiffres seront
|> au final suffisant ??
Qu'il suffisse ou non, c'est (au moins pour certains calculs) la loi.
|> par exemple est-ce qu'une banque pourrait décider de faire les
|> calculs d'interêt en sommant des interêts par intervalle de
|> temps très court afin d'avoir un gros décalage sur la somme
|> finale ?
Comment la somme se fait, et sur quoi on arrondit, et bien
précisé. Donc, par exemple, si tu as une facture avec beaucoup de
petites postes en francs, la loi exige que la somme se fait sur les
francs, et que la conversion en Euro se fait une fois, à la fin.
En ce qui concerne la TVA, c'est plus compilqué, dans la mésure
que les prix affichés de chaque article le comprend déjà.
N'empêche que le montant que doit payer le commerçant, ce n'est
pas la somme des TVA de chaque article, mais la TVA sur la somme des
prix hors-taxe.
|> ah mais en fait pour éviter ça il suffit d'obliger que toute
|> imprécision de calcul soit en défaveur de celui qui fait le
|> calcul, j'imagine.
La loi est très précise sur la façon que doit se faire le
calcul, et qui que ce soit qui le fait doit forcément retrouver le
même résultat.
|> il y a des matheux qui sont chargés de vérifier ça qque
|> part ?
Est-ce que la loi est enforcée, tu veux dire ? Je ne sais pas --
systèmatiquement, sûrement pas, mais s'il y a un contrôle
fiscal...
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> > La législation sur l'Euro exige que les calculs se font avec |> > cinque chiffres après le décimal, avec le résultat final |> > arrondi à deux chiffres.
|> et la loi arrive à formuler une contrainte sur la façon de |> faire les calculs permettant de s'assurer que ces 5 chiffres seront |> au final suffisant ??
Qu'il suffisse ou non, c'est (au moins pour certains calculs) la loi.
|> par exemple est-ce qu'une banque pourrait décider de faire les |> calculs d'interêt en sommant des interêts par intervalle de |> temps très court afin d'avoir un gros décalage sur la somme |> finale ?
Comment la somme se fait, et sur quoi on arrondit, et bien précisé. Donc, par exemple, si tu as une facture avec beaucoup de petites postes en francs, la loi exige que la somme se fait sur les francs, et que la conversion en Euro se fait une fois, à la fin.
En ce qui concerne la TVA, c'est plus compilqué, dans la mésure que les prix affichés de chaque article le comprend déjà. N'empêche que le montant que doit payer le commerçant, ce n'est pas la somme des TVA de chaque article, mais la TVA sur la somme des prix hors-taxe.
|> ah mais en fait pour éviter ça il suffit d'obliger que toute |> imprécision de calcul soit en défaveur de celui qui fait le |> calcul, j'imagine.
La loi est très précise sur la façon que doit se faire le calcul, et qui que ce soit qui le fait doit forcément retrouver le même résultat.
|> il y a des matheux qui sont chargés de vérifier ça qque |> part ?
Est-ce que la loi est enforcée, tu veux dire ? Je ne sais pas -- systèmatiquement, sûrement pas, mais s'il y a un contrôle fiscal...
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
