C'est exactement ça ! L'API peut parfaitement prévenir l'utilisateur, à la compilation, que le nombre de digits demandé n'est pas suffisant pour garantir l'exactitude du calcul des taux et le client de l'API devra réviser ses exigences à l'instanciation de son type "monnaie".
En gros: tu peux aller en valeur absolue jusqu'à 10 puissance 12 et une précision de 7 digits après la virgule sans problème (c'est largement suffisant pour assurer les exigences européennes de conversion de devises dont parlait Kantien). Tu peux même créer des pré et post conditions dans la fonction "round" pour être averti, par une levée d'exception, que tu demandes l'impossible. Jamais le flottant ne te permettra d'avoir ce niveau de contrôle puisqu'il mange tout ce qu'on lui donne sans broncher.
Et même si on regarde sur le plan mathématique, une analyse rapide montre qu'il est absurde d'utiliser un type decimal flottant codé en hard pour répondre au problème de la représentation de valeurs monétaires. Je m'explique:
on se confronte au phénomène de "cancellation". C'est à dire que si u=10^{14} et v=10^{-4} alors (u+v)-u perd quasiment tous ses chiffres significatifs et donc si on multiplie derrière par un entier assez grand, on obtiendra (silencieusement !!) quelque chose de complètement faux. Rien de pire que les erreurs silencieuses (donc détectables uniquement quand la catastrophe s'est produite)
si on note e le nombre de bits occupés par l'exposant dans la représentation machine du flottant (disons sur 64 bits), on voit qu'on n'utilise qu'un tout petit nombre valeurs possibles codées par les e bits (disons 16 pour fixer les idées). C'est à dire que sur les 2^{64} valeurs possibles du flottant décimal, seules environ un 64ème de ces valeurs sont utiles. En virgule fixe, on utilise vraiment les 2^{64} valeurs possibles. Cette perte d'informations montre à elle seule que le flottant n'est pas adapté à la situation dont on parle.
un dernier avantage concernant les perfs: la virgule fixe c'est de la gestion d'addition/soustraction d'entiers dans le backend FPU. C'est donc bien plus efficace que de manipuler du float au niveau FPU (2 voire 6 fois plus rapide en moyenne suivant le FPU utilisé).
A quel problème informatique répond le concept de virgule fixe ? Réponse: il a été fait spécialement pour gérer un nombre fini de points (de façon exacte) uniformément répartis dans un intervalle borné; typiquement... une monnaie :)
[^] # 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é à 4. Dernière modification le 29 janvier 2018 à 14:14.
C'est exactement ça ! L'API peut parfaitement prévenir l'utilisateur, à la compilation, que le nombre de digits demandé n'est pas suffisant pour garantir l'exactitude du calcul des taux et le client de l'API devra réviser ses exigences à l'instanciation de son type "monnaie".
En gros: tu peux aller en valeur absolue jusqu'à 10 puissance 12 et une précision de 7 digits après la virgule sans problème (c'est largement suffisant pour assurer les exigences européennes de conversion de devises dont parlait Kantien). Tu peux même créer des pré et post conditions dans la fonction "round" pour être averti, par une levée d'exception, que tu demandes l'impossible. Jamais le flottant ne te permettra d'avoir ce niveau de contrôle puisqu'il mange tout ce qu'on lui donne sans broncher.
Et même si on regarde sur le plan mathématique, une analyse rapide montre qu'il est absurde d'utiliser un type decimal flottant codé en hard pour répondre au problème de la représentation de valeurs monétaires. Je m'explique:
A quel problème informatique répond le concept de virgule fixe ? Réponse: il a été fait spécialement pour gérer un nombre fini de points (de façon exacte) uniformément répartis dans un intervalle borné; typiquement... une monnaie :)