"Si on a du float ou double pour du monétaire, la réponse est clairement "non". "
Je répondais à cette phrase-ci.
"Et ce nonobstant toutes les explications qu'on t'a données. C'est un peu dommage."
J'ai quand même appris plein de truc. Mais je trouve qu'il n'y a pas d'exemple d'horror story et beaucoup de "on dit".
J'ai appris l'existence de l'arrondis bancaire, ainsi que les règles d'arrondis pour la TVA. Cela peut se faire avec n'importe quel type. Je me suis rendu compte que le type DECIMAL qui code exactement certain nombre décimal évite le problème de l'accumulation d'erreur d'un nombre flottant, mais c'est valide pour la somme d'un très grand nombre de ligne. Cela peut aussi se faire avec un simple entier qui représente des centimes. Les IO d'argent se font uniquement en centimes.
C'est déjà pas mal !
La où on ne m'a pas convaincu, c'est l'obligation d'utiliser un type DECIMAL dans mes calculs internes comme le propose certain langage.
[^] # Re: nan, c'est pas un problème d'arrondi qui te guette
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 4.
Je répondais à cette phrase-ci.
J'ai quand même appris plein de truc. Mais je trouve qu'il n'y a pas d'exemple d'horror story et beaucoup de "on dit".
J'ai appris l'existence de l'arrondis bancaire, ainsi que les règles d'arrondis pour la TVA. Cela peut se faire avec n'importe quel type. Je me suis rendu compte que le type DECIMAL qui code exactement certain nombre décimal évite le problème de l'accumulation d'erreur d'un nombre flottant, mais c'est valide pour la somme d'un très grand nombre de ligne. Cela peut aussi se faire avec un simple entier qui représente des centimes. Les IO d'argent se font uniquement en centimes.
C'est déjà pas mal !
La où on ne m'a pas convaincu, c'est l'obligation d'utiliser un type DECIMAL dans mes calculs internes comme le propose certain langage.
"La première sécurité est la liberté"