Je m'arrête là pour le fond et je conteste cette partie de la spécification que tu proposes (sinon tout le reste s'ensuit bien, comme il se doit, sur le plan mathématique : je conteste ta première prémisse). [...devises différentes à prendre en compte]
suivi de
Wherever these conversion rates are used, they will have to be applied exactly,
Si tu dois faire des conversion entre des € et une devise A où 1,000_000 € = 1,500_000 A, il t'apporte quoi le flottant décimal ? Il ne fera pas mieux que le flottant binaire pour la conversion de A vers €.
Mais de toute façon, ça ne pose aucun problème: tu gères tout dans une monnaie (disons l'euro avec virgule fixe) et convertir d'une devise à l'autre avec 6 décimales exactes comme exigé ne pose pas le moindre problème (mon arrondi au centime en Ada n'était qu'un exemple et rien n'empêche d'aller chercher 6 décimales exactes).
Il n'y a aucune mauvaise foi, c'est bien un problème d'API. Un programmeur qui a besoin de décimaux veut pouvoir écrire : arrondi moi ce nombre à la deuxième décimal selon telle règle d'arrondis. Autrement dit, il veut quelque chose du genre : Decimal.(round 2 (dec "0.70" * dec "1.05"))
Et comment tu lui dis à Python comment il doit arrondir sachant que les règles d'arrondi tu en as quasiment une par pays ! cf https://en.wikipedia.org/wiki/Cash_rounding
Python ne peut pas connaître toutes ces règles ! L'arrondi ne sera jamais out-of-the-box. La norme IEEE754 (décimale ou non) ne proposera jamais quoique ce soit pour répondre à la diversité de ces règles (et encore heureux !). Tu as une fonction qui permet de faire round ("irlande",4.6789987,2) ?
Toi ce que tu dis, c'est que l'on peut prendre t = float et définir round de façon à ce qu'il se comporte correctement. Ce à quoi je t'ai répondu : personne ne l'a jamais nié, mais le programmeur ne veut pas avoir à faire ça à la main,
Qu'il pleure ou qu'il gémisse, il devra de toute façon le faire car il n'a pas le choix, vu qu'il y a plus de règles d'arrondis dans le monde qu'il n'y a de modes d'arrondi définis par la norme IEEE754 décimale (remarque au passage que cette norme ne propose rien de plus que la norme classique en terme de nombre de modes d'arrondis: 3 modes différents qui ne portent de toute façon que sur le dernier ulp. De toute façon le décimal ne propose rien pour l'arrondi à la mode irlandaise ou norvégienne etc.
Pour synthétiser:
Pour les conversions de devise exactes: le flottant décimal n'apporte absolument rien par rapport au flottant binaire (exemple 1€ <---> 1,5A ça te sert à quoi le flottant décimal pour passer de A à € ?). De toute façon le flottant binaire suffit amplement pour appliquer scrupuleusement l'exactitude au millionième près.
Les règles d'arrondi sont tellement diverses (presque une par pays !) qu'aucune norme ne pourra dispenser le programmeur en économat de produire le code ad hoc.
La seule chose que doit faire le programmeur c'est de coder cet arrondi: tout le reste c'est out of the box en virgule fixe (normal, ça a été fait pour ça).
Si tu utilises du flottant ça peut devenir la foire à la saucisse dans le code si le programmeur "ne veut pas trop se prendre la tête". Au contraire, l'emploi de la virgule fixe façon Ada, empêche le programmeur en amont de faire n'importe quoi: les erreurs grossières ne doivent jamais rester silencieuses (à la compilation, le flottant sera toujours silencieux, au runtime idem, à moins de taper dans du 10 puissance 300 et des brouettes.
Rien de de que dit Muller dans le lien que tu me donnes ne contredit tout cela (ou alors j'ai raté un passage). Le flottant décimal a des utilisations pratiques mais pour les besoins de Dring, ça n'a aucun intérêt.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par snowball (site web personnel) . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 2.
suivi de
Si tu dois faire des conversion entre des € et une devise A où 1,000_000 € = 1,500_000 A, il t'apporte quoi le flottant décimal ? Il ne fera pas mieux que le flottant binaire pour la conversion de A vers €.
Mais de toute façon, ça ne pose aucun problème: tu gères tout dans une monnaie (disons l'euro avec virgule fixe) et convertir d'une devise à l'autre avec 6 décimales exactes comme exigé ne pose pas le moindre problème (mon arrondi au centime en Ada n'était qu'un exemple et rien n'empêche d'aller chercher 6 décimales exactes).
Et comment tu lui dis à Python comment il doit arrondir sachant que les règles d'arrondi tu en as quasiment une par pays ! cf https://en.wikipedia.org/wiki/Cash_rounding
Python ne peut pas connaître toutes ces règles ! L'arrondi ne sera jamais out-of-the-box. La norme IEEE754 (décimale ou non) ne proposera jamais quoique ce soit pour répondre à la diversité de ces règles (et encore heureux !). Tu as une fonction qui permet de faire round ("irlande",4.6789987,2) ?
Qu'il pleure ou qu'il gémisse, il devra de toute façon le faire car il n'a pas le choix, vu qu'il y a plus de règles d'arrondis dans le monde qu'il n'y a de modes d'arrondi définis par la norme IEEE754 décimale (remarque au passage que cette norme ne propose rien de plus que la norme classique en terme de nombre de modes d'arrondis: 3 modes différents qui ne portent de toute façon que sur le dernier ulp. De toute façon le décimal ne propose rien pour l'arrondi à la mode irlandaise ou norvégienne etc.
Pour synthétiser: