Pour faire le teste, il faudrait générer quelques millions de nombre et faire la somme, et recommencer avec des nombres arrondis et estimer l'erreur final. Le "round to even" devrait avoir une erreur plus faible.
Si tu manipules une masse de truc tu finis souvent par faire des tables temporaires pour continuer des calculs. J'ai l'impression que c'est fini le fait de ne stocker que les données "raw", des étapes intermédiaires peuvent être stocker aussi.
Maintenant, si tu additionnes 2 millions de nombres avec chacun ce type d'erreur, les erreurs s'additionnent, et le résultat pourra être faux de manière imprévisible, même si on ne fait aucun arrondi intermédiaire.
Pas de manière imprévisible, cela peut tout à fait se calculer. si tu n'as que des additions, tu as n opérations, donc n * l'erreur au maximum erreur de 10-7 ou 10-16 (float32 ou float64). Avec des montants inférieur au milliard d'euro, tu peux faire quelques milliers d'addition en float64 avant d'avoir un soucis. Avec 2 millions d'addition, tu ne pourra pas en effet.
Avec du décimal, on additionnerait des valeurs exactes, et le résultat serait donc exact.
Oui dans le cas simple d'addition sans arrondi ni overflow.
Je viens de penser à un truc, si tu factures avec la méthode 2 qui calcul avec arrondi chaque ligne pour avoir des sommes de TVA facile à avoir, il est possible d'avoir de la TVA à zéro avec des toutes petites sommes facturées ?!
Genre tu factures une ligne 0.20€ ttc tu as 0.2*.02 = 0.004 € de TVA qui s'arrondissent à 0 ?
C'est typiquement ce qui arrive avec des arrondis qui traine dans les calculs intermédiaires. Si le logiciels ne faisaient jamais d'arrondis (sauf à l'affichage), il n'y aura pas de problème.
Ce sont les ingrédients idéaux pour voir apparaître des erreurs d'arrondi en virgule flottante.
Les calcul en DECIMAL posent exactement les mêmes problèmes. La solution du secteurs bancaires semble d'avoir redéfinit ses propres opérateurs qui se traduise avec l'arrondis bancaire, si je comprends bien les autres commentaires. Il est tout à fait possible de suivre les mêmes règles avec du code utilisant des flottants.
Il faut que je lise ton 1) plus complètement, mais il me semble écrit par un mathématicien qui parle du cas général et non du cas habituel. Dans un système habituel, les entrée ont aussi une part d'imprécision (en gros, toute entrée de capteurs) et donc, il n'y a jamais aucun algo utilisé qui "divergent" ou qui est chaotique.
En général, l'erreur est de 1/2 lsb par opération max, mais le "round to even" fait qu'en moyenne c'est beaucoup moins. De plus, souvent les fpu ont plus de précision que les 64 bits de base (80 bits pour la fpu x87, opération a*b+c en une seul passe). Il prend pour exemple la soustraction qui est le pire cas, car si a et b sont du même ordre de grandeur, il ne reste plus que l'erreur, ce qui est "physiquement" normal.
c'est vraiment 1,2 (qui n'est même pas représentable exactement en flottant).
Oui mais on s'en fout en fait, car tu peux faire tout les calculs que tu veux du moment que tu restes dans les 1016 d'amplitude. C'est une histoire d'arrondis ensuite.
mais ça ne simplifie pas vraiment la question par rapport à faire tous les calculs exacts en comptant des nombres entiers de centimes (ce qui revient à compter les euros en virgule fixe).
C'est plus compliqué que ça. Sinon, ton résultat final varie en fonction du nombre d'intermédiaire de calcul que tu utilises.
Ce genre de "dérive" à long terme, se gère en automatisme par un intégrateur. Je ne sais pas si cela se fait dans le secteur bancaire, mais avec la sauvegarde de l'erreur dans un coin, on peut la refacturer la fois suivante.
Je comprends mieux. Le problème n'est pas du tout DECIMAL vs double. C'est uniquement que les transferts se font en centime et rien d'autre, et qu'il faut gérer correctement les arrondis.
quel différence avec un double correctement utilisé ? si on suit ta méthode, un double est constitué de 2 INTEGER, l'un de 54 bits et l'autre de 16. Et leur gestion est directement pris en charge par les fpu. Et si tu prends 10x, cela revient à utiliser le type DECIMAL mais sans pouvoir changer la précision.
Pourquoi s’embêter avec un truc aussi complexe ? Quel erreur tu évites ainsi ?
Sinon certains SGBD (dont PostgreSQL) ont un type pour le monétaire, mais j'ai jamais testé.
MONEY pour postresql, c'est DECIMAL(10,2), autant prendre DECIMAL tout court qui est plus précis.
De mémoire, c'était les retours d'une expérience dans un pays du nord, genre Pays-Bas ou Danemark. Je n'ai plus la source en tête.
Ne pas oublier que ce qui est couteux est uniquement le traitement des eaux sales, c'est pour cela qu'il y a des compteurs agricoles car l'eau va dans le sol. C'est pour ça aussi qu'il est interdit d'utiliser de l'eau de pluie pour les toilettes, car le retraitement n'est pas payé.
"balancer de l'eau potable, traitée, dans les toilettes sont simplement stupide…"
Non en fait, c'est très réfléchi. Certaines personnes utilisaient de l'eau de pluie ou de l'eau "peu sale" comme celle du lavabo ou de la douche. Résultat : beaucoup d'infections bactériennes, les fines projection d'eau lors du tirage de la chasse d'eau suffisait pour contaminer l'usager.
[^] # Re: Exemple simple
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
Il y a moins d'erreur à la fin.
Pour faire le teste, il faudrait générer quelques millions de nombre et faire la somme, et recommencer avec des nombres arrondis et estimer l'erreur final. Le "round to even" devrait avoir une erreur plus faible.
"La première sécurité est la liberté"
[^] # Re: Un retour d'expérience
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
Si tu manipules une masse de truc tu finis souvent par faire des tables temporaires pour continuer des calculs. J'ai l'impression que c'est fini le fait de ne stocker que les données "raw", des étapes intermédiaires peuvent être stocker aussi.
"La première sécurité est la liberté"
[^] # Re: "double" et "long double"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
La dernière version du IEE754 ajoute un type décimal (BCD ?) qui doit être supporté dans les dernières versions de GCC.
"La première sécurité est la liberté"
[^] # Re: Le point clef est le calcul scientifique, pas la finance
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Le DECIMAL en sql, est plus une virgule fixe. Même si des implémentations particulières peuvent avoir des tailles variables.
"La première sécurité est la liberté"
[^] # Re: Exemple simple
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
En quoi cet arrondis n'est pas classique ? C'est le mode par défaut des fpu.
"La première sécurité est la liberté"
[^] # Re: "10.222" n'existe pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 4.
Je me doutais un peu.
"La première sécurité est la liberté"
[^] # Re: Monnaie = danger
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Oui, il faut faire attention aussi que le langage hôte ne fasse pas de conversion en double sans prévenir.
"La première sécurité est la liberté"
[^] # 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é à 3.
Pas de manière imprévisible, cela peut tout à fait se calculer. si tu n'as que des additions, tu as n opérations, donc n * l'erreur au maximum erreur de 10-7 ou 10-16 (float32 ou float64). Avec des montants inférieur au milliard d'euro, tu peux faire quelques milliers d'addition en float64 avant d'avoir un soucis. Avec 2 millions d'addition, tu ne pourra pas en effet.
Oui dans le cas simple d'addition sans arrondi ni overflow.
"La première sécurité est la liberté"
[^] # 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é à 3.
Mais cela n'a pas d'importance !
si float x = 30.14
Cela veut dire que 30.14+10-7>= x >= 30.14-10-7 (en gros)
donc "30.139999" arrondit à 6 chiffres donnent bien 30.14.
"La première sécurité est la liberté"
[^] # Re: "10.222" n'existe pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Je viens de penser à un truc, si tu factures avec la méthode 2 qui calcul avec arrondi chaque ligne pour avoir des sommes de TVA facile à avoir, il est possible d'avoir de la TVA à zéro avec des toutes petites sommes facturées ?!
Genre tu factures une ligne 0.20€ ttc tu as 0.2*.02 = 0.004 € de TVA qui s'arrondissent à 0 ?
"La première sécurité est la liberté"
[^] # Re: Le point clef est le calcul scientifique, pas la finance
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
C'est typiquement ce qui arrive avec des arrondis qui traine dans les calculs intermédiaires. Si le logiciels ne faisaient jamais d'arrondis (sauf à l'affichage), il n'y aura pas de problème.
Les calcul en DECIMAL posent exactement les mêmes problèmes. La solution du secteurs bancaires semble d'avoir redéfinit ses propres opérateurs qui se traduise avec l'arrondis bancaire, si je comprends bien les autres commentaires. Il est tout à fait possible de suivre les mêmes règles avec du code utilisant des flottants.
"La première sécurité est la liberté"
[^] # 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.
Facile si tu n'as que des additions. Si tu dois faire des divisions, cela commence à devenir sportif en entier.
"La première sécurité est la liberté"
[^] # 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é à 3.
float est sur 32 bits, la mantisse est sur 24 bits soit 7 chiffres significatifs. Le résulat est tout à fait logique.
"La première sécurité est la liberté"
[^] # Re: Propagation d'erreurs, éléphants et souris
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Il faut que je lise ton 1) plus complètement, mais il me semble écrit par un mathématicien qui parle du cas général et non du cas habituel. Dans un système habituel, les entrée ont aussi une part d'imprécision (en gros, toute entrée de capteurs) et donc, il n'y a jamais aucun algo utilisé qui "divergent" ou qui est chaotique.
En général, l'erreur est de 1/2 lsb par opération max, mais le "round to even" fait qu'en moyenne c'est beaucoup moins. De plus, souvent les fpu ont plus de précision que les 64 bits de base (80 bits pour la fpu x87, opération a*b+c en une seul passe). Il prend pour exemple la soustraction qui est le pire cas, car si a et b sont du même ordre de grandeur, il ne reste plus que l'erreur, ce qui est "physiquement" normal.
"La première sécurité est la liberté"
[^] # Re: Cumul des arrondis
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Oui mais on s'en fout en fait, car tu peux faire tout les calculs que tu veux du moment que tu restes dans les 1016 d'amplitude. C'est une histoire d'arrondis ensuite.
C'est plus compliqué que ça. Sinon, ton résultat final varie en fonction du nombre d'intermédiaire de calcul que tu utilises.
"La première sécurité est la liberté"
[^] # Re: Cumul des arrondis
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
C'est cette phrase qui m'a fait penser à ça :
"La première sécurité est la liberté"
[^] # Re: Cumul des arrondis
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Ce genre de "dérive" à long terme, se gère en automatisme par un intégrateur. Je ne sais pas si cela se fait dans le secteur bancaire, mais avec la sauvegarde de l'erreur dans un coin, on peut la refacturer la fois suivante.
"La première sécurité est la liberté"
[^] # Re: "10.222" n'existe pas
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Je comprends mieux. Le problème n'est pas du tout DECIMAL vs double. C'est uniquement que les transferts se font en centime et rien d'autre, et qu'il faut gérer correctement les arrondis.
"La première sécurité est la liberté"
[^] # Re: Monnaie = danger
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 5.
quel différence avec un double correctement utilisé ? si on suit ta méthode, un double est constitué de 2 INTEGER, l'un de 54 bits et l'autre de 16. Et leur gestion est directement pris en charge par les fpu. Et si tu prends 10x, cela revient à utiliser le type DECIMAL mais sans pouvoir changer la précision.
Pourquoi s’embêter avec un truc aussi complexe ? Quel erreur tu évites ainsi ?
MONEY pour postresql, c'est DECIMAL(10,2), autant prendre DECIMAL tout court qui est plus précis.
"La première sécurité est la liberté"
[^] # Re: Un retour d'expérience
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
Tout cela c'est valide pour un prix de transfert final, mais pour tous calcul intermédiaire, on ne peut se contenter de 2 chiffres après la virgule.
"La première sécurité est la liberté"
[^] # Re: Un retour d'expérience
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
c'est un "round to nearest".
"La première sécurité est la liberté"
[^] # Re: corrélation réchauffement climatique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 3. Dernière modification le 11 septembre 2017 à 14:37.
De mémoire, c'était les retours d'une expérience dans un pays du nord, genre Pays-Bas ou Danemark. Je n'ai plus la source en tête.
Ne pas oublier que ce qui est couteux est uniquement le traitement des eaux sales, c'est pour cela qu'il y a des compteurs agricoles car l'eau va dans le sol. C'est pour ça aussi qu'il est interdit d'utiliser de l'eau de pluie pour les toilettes, car le retraitement n'est pas payé.
"La première sécurité est la liberté"
[^] # Re: "sur quels critères ?"
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Recrutons. D'accord, mais sur quels critères ?. Évalué à 3.
C'est sur que si Zenitram est aussi abrasif dans la vie que sur linuxfr, cela doit être sportif de bosser pour lui :)
"La première sécurité est la liberté"
[^] # Re: corrélation réchauffement climatique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 4.
Non en fait, c'est très réfléchi. Certaines personnes utilisaient de l'eau de pluie ou de l'eau "peu sale" comme celle du lavabo ou de la douche. Résultat : beaucoup d'infections bactériennes, les fines projection d'eau lors du tirage de la chasse d'eau suffisait pour contaminer l'usager.
"La première sécurité est la liberté"
[^] # Re: Exceptionnel ou systémique ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le jour d’après, c’est aujourd’hui. Évalué à 4.
Est-ce que ton dernier phénomène à avoir avec les geyser ou pas du tout ?
"La première sécurité est la liberté"