URL: https://linuxfr.org/users/niconico/journaux/sql-decimal-vs-double Title: SQL Decimal vs Double Authors: Nicolas Boulay Date: 2017年09月11日T15:02:12+02:00 License: CC By-SA Tags: Score: 13 Pour des calculs financiers, il est conseillé souvent d'utiliser le type DECIMAL et non un type float classique pour stocker des montant d'argent. L'argument principal est que DECIMAL n'arrondit pas, au contraire de float. Mais c'est complètement faux. Un type DECIMAL(10,2), a 10 chiffres significatifs, et 2 chiffres après la virgule. Donc, "10.222" sera tronqué à "10.22", ce qui est un arrondit violent. A l'inverse, il est vrai que "0.1" sera stocké exactement en DECIMAL, et par une approximation avec un flottant. L'approximation sera de 10^-16 avec un double, ce qui laisse une bonne marge. J'ai cherché des exemples d'"horror story" avec les calculs financiers, j'ai juste trouvé une personne qui propose d'utiliser un entier à la place de DECIMAL, mais je ne vois pas de nombre 32 bits qui ne se stocke pas dans un double. Certains parlent aussi du fait de ne pas utiliser d'opérateur = ou avec des flottants, mais c'est la base de la base en calcul flottant, car chaque calcul porte le 10^-16 d'imprécision en lui. L'autre règle est de ne pas additionner des "éléphants et des souris", car l'étape de normalisation/shift peut introduire de grosse erreur (genre 10^16 +0.01 = 10^16) Les nombres flottants disposent d'arrondi bien défini, celui de base, le "round to even" est celui qui propose le moins d'erreur quand on somme un grand nombre de nombre. Avez vous des exemples de code qui se comportent réellement mal spécifiquement de le cas monétaire ? Qu'est-ce qu'il y a de plus compliqué que du code flottant classique ?

AltStyle によって変換されたページ (->オリジナル) /