Le moment où tu n'as plus en tête tout le pipeline de traitement.
Ça, de toutes façons, même Rust n'y pourra pas grand chose.
Si justement, Rust te garanti d'avoir un seul propriétaire de la mémoire, tu ne peux pas avoir 2 pointeurs qui se baladent, c'est plus facile à suivre. C'est le principe de ce genre de contrainte, avoir une sémantique clair et simple.
Franchement, réutiliser des array de mémoire sans copie est un moyen de faire un code très rapide qui use peu de mémoire, mais c'est aussi le meilleur moyen de se tirer une balle dans le pied, car il peut devenir très compliquer de savoir quel traitement à déjà eu lieu et l'état réel du buffer.
Donc, que rust propose de vérifier des propriétés qui te garantissent que tu ne fais pas de la merde, c'est pas mal. Regardes les perfs qu'il obtient à la fin, et surtout la consommation mémoire.
"4.5*.93 = 4.185+ε (avec ε positif), en arrondi bancaire 4.19"
Le truc c'est le ε qui traine, qui fait une bascule. Mais même un décimal ne peut pas stocker tous les nombre de façon exact (1/3,1/7, sqrt(2), e, Pi…), pour toi, il n'existe pas de cas pathologique similaire ?
Tu as toujours le ((a-1)*n) + (a * n) = n, pour n dans [0;1] ? Et c'est vrai aussi pour plus de 2 termes ? avec du calcul décimal.
Oui, c'est très connu comme papier. Et une source infini de problème provient du fait que les optimiseurs de certain compilateur prennent les flottants pour des réels.
"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.
Je suis désolé, car c'est faux. J'ai un cas qui a besoin d'une division, le type monétaire ne contient pas assez de décimal pour ne pas faire d'erreur grossière au final. Ce que tu dis n'est vrai que pour des transferts ou la valeur de compte courant. Bref, pour les IO mais surtout pas pour des calculs internes.
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.
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 7.
Le moment où tu n'as plus en tête tout le pipeline de traitement.
Si justement, Rust te garanti d'avoir un seul propriétaire de la mémoire, tu ne peux pas avoir 2 pointeurs qui se baladent, c'est plus facile à suivre. C'est le principe de ce genre de contrainte, avoir une sémantique clair et simple.
"La première sécurité est la liberté"
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 3.
Au début seulement, si le code ne devient pas gros, et si personne n'a corrigé de bug avec un emplâtre mal placé.
"La première sécurité est la liberté"
[^] # Re: Gnirehtet réécrit en Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Du reverse tethering, en Rust. Évalué à 6.
Franchement, réutiliser des array de mémoire sans copie est un moyen de faire un code très rapide qui use peu de mémoire, mais c'est aussi le meilleur moyen de se tirer une balle dans le pied, car il peut devenir très compliquer de savoir quel traitement à déjà eu lieu et l'état réel du buffer.
Donc, que rust propose de vérifier des propriétés qui te garantissent que tu ne fais pas de la merde, c'est pas mal. Regardes les perfs qu'il obtient à la fin, et surtout la consommation mémoire.
"La première sécurité est la liberté"
[^] # Re: On en est arrivé là comment ?!
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche devops REX - publication du programme du 2 octobre 2017. Évalué à 3.
Etre un gros lourd, un peu con, n'est pas encore illégal, d’où le rajout de règle, j'imagine.
"La première sécurité est la liberté"
[^] # Re: lieu
Posté par Nicolas Boulay (site web personnel) . En réponse au journal C'est la rentrée, un timing parfait pour un meetup Open Hardware sur Paris @Criteo . Évalué à 4.
Au début de la rue, il y a la bonbonnière de la trinité, je recommande très chaudement : un des meilleurs chocolatiers de Paris.
"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.
Tu parles de ça : https://linuxfr.org/users/niconico/journaux/sql-decimal-vs-double#comment-1713014 ?
J'ai du le louper.
Le truc c'est le ε qui traine, qui fait une bascule. Mais même un décimal ne peut pas stocker tous les nombre de façon exact (1/3,1/7, sqrt(2), e, Pi…), pour toi, il n'existe pas de cas pathologique similaire ?
Tu as toujours le ((a-1)*n) + (a * n) = n, pour n dans [0;1] ? Et c'est vrai aussi pour plus de 2 termes ? avec du calcul décimal.
"La première sécurité est la liberté"
[^] # Re: Pour info
Posté par Nicolas Boulay (site web personnel) . En réponse au journal SQL Decimal vs Double. Évalué à 3. Dernière modification le 13 septembre 2017 à 17:11.
Oui, c'est très connu comme papier. Et une source infini de problème provient du fait que les optimiseurs de certain compilateur prennent les flottants pour des réels.
"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.
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é"
[^] # 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é à 0.
Je suis désolé, car c'est faux. J'ai un cas qui a besoin d'une division, le type monétaire ne contient pas assez de décimal pour ne pas faire d'erreur grossière au final. Ce que tu dis n'est vrai que pour des transferts ou la valeur de compte courant. Bref, pour les IO mais surtout pas pour des calculs internes.
"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.
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é"