Donc, dans les bouquins de mathématiques, (une fraction x - une fraction x) = 0 , (un complexe x - un complexe x) = 0, et même (un ensemble x - un ensemble x) c'est l'ensemble vide (i.e. le "0" des ensembles).
Chez les flottants aussi, x-x=0.
c) oui également, Decimal est effectivement un moyen de cacher/surcharger/contourner ce qui "tracasse"
Pas vraiment. Ça ne règle le problème Decimal (x) * Decimal (1/x) = Decimal (1) que quand x est de la forme 2*n * 5*m, c'est à dire quasiment jamais (même pas pour x=3 !!).
Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.
Les floats que propose Python sont à destination du milieu geek "conditionné" (i.e qui comprend ce qu'est un float). Python n'est pas une calculatrice. Mais de toute façon, toute personne qui a déjà utilisé sa calculatrice est déjà habituée aux résultats approchés même pour des calculs évidents du genre 3 * 1/3 = 1 et ça ne fait pas sourire. Elle se rend juste compte qu'une machine qui ne gère que du fini, ne peut gérer exactement les nombres: elle ne peut faire, quasiment à chaque fois, que des approximations.
une simple calculatrice scientifique qui couvre correctement son domaine de fonctionnement (exact pour les décimaux usuels, notation ingénieur/scientifique ailleurs)
Non. Une calculatrice de base "se trompe" sur 1.000 000 1 * 0.999 999 9 qui sont deux décimaux très "raisonnables". Elle "se trompe" quasiment sur tous les calculs impliquant les décimaux (en fait la probabilité qu'une calculatrice donne un résultat juste dès qu'elle fait des multiplications ou divisions sur des décimaux aléatoires est de moins d'un milliardième (si on considère une machine sachant gérer 13 chiffres de mantisse).
Cela est donc bien possible.
En fait, bc fait
01:53:35 ~: bc
bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
1.01*0.99
.99
C'est à dire un résultat faux. Alors oui, tu peux évidemment pousser la mantisse utilisée par bc un peu plus si tu es "conditionné" aux problèmes que pose le calcul numérique sur une machine, mais tu tomberas sur le même problème un tout petit peu plus loin.
On peut, modulo des coûts de calcul très importants, colmater quelques erreurs (une sur un milliard environ) mais on ne peut pas régler le problème tout court. Il y aura toujours des calculs quasi évidents qui ne seront pas correctement effectués par une machine.
Mais ça interpelle. C'est tout.
Tout comme ça m'a interpellé quand j'ai vu que presque tous les calculs faits par une calculatrice sont faux (sauf pour quelques opérations sur certains décimaux qui donnent une illusion d'exactitude au néophyte)
PS : Ah oui, en La(TeX) aussi c'est bon à première vue, 0.2+0.4 donne 0.60000 ;-)
Il a tronqué un résultat faux au moment de l'affichage et qui du coup redonne une impression d'exactitude du calcul (il arrondit un arrondi faux qui redonne un résultat "exact" )
PS2 : 4ème implémentation déjà évoquée, un tableur. Ça se comporte, suffisamment bien, que ce soit pour les décimaux que pour des valeurs grandes.
Non. Ça fait les mêmes bêtises, puis ça les cache avec des algos qui tentent de prédire ce que veut probablement l'utilisateur (en fonction de la configuration de l'arrondi dans le format de cellule). Calc utilise des floats derrière ton dos, fait, comme toute machine, les mêmes approximations, puis formate l'affichage pour qu'avec certains décimaux tu aies l'illusion que son calcul est juste, ce qui, évidemment, n'est pas vrai dans presque tous les cas.
En fait, il n'y a pas vraiment de problème:
Si tu veux une addition / soustraction exacte des "petits" décimaux, tu as des modules pour ça (par contre ils vont se vautrer quasiment sur chaque division, même élémentaire) et ça va coûter cher en perf.
Si tu as compris, que de toute façon, le calcul juste sur une machine n'arrive que dans quelques cas exceptionnels et qu'une précision aux alentours du 17ème chiffre après la virgule te suffit alors tu as les floats (avec beaucoup d'efficacité machine).
Dans 99% des cas d'utilisation, l'exactitude souhaitée sur quelques rares petits décimaux n'ayant aucun intérêt, et coûtant environ 50 fois plus de cycles d'horloge qu'un calcul avec des floats, on n'a que très rarement l'intérêt d'utiliser le module decimal.
Bref, on a une solution informatique convenable à quasiment tous les problèmes numériques usuels en fonction de chaque besoin spécifique.
Les sciences (mathématique/informatique) ont fait depuis longtemps le tour théorique de cette question en délimitant (démonstration à l'appui) précisément ce qu'on peut faire et ce que l'on ne peut pas faire, ce qu'il est intéressant de faire ou ce qu'il faut éviter de faire dans le domaine de la représentation des nombres en machine.
Tout cela a déjà été dit, dans les posts au dessus, mais certaines incompréhensions ayant nécessité beaucoup d'explications ont fini par noyer les messages très clairs donnés par beaucoup d'intervenants.
Les incompréhensions, quand on creuse un peu, viennent de représentations erronées de la nature même des nombres. Ce n'est pas étonnant car ces concepts sont en fait loin d'être évidents à comprendre surtout quand on croit (sincèrement) les maîtriser.
[^] # Re: Commentaire de soutien ;-)
Posté par snowball (site web personnel) . En réponse au journal [Humour] vers un monde différent. Évalué à 2.
Chez les flottants aussi, x-x=0.
Pas vraiment. Ça ne règle le problème Decimal (x) * Decimal (1/x) = Decimal (1) que quand x est de la forme 2*n * 5*m, c'est à dire quasiment jamais (même pas pour x=3 !!).
Les floats que propose Python sont à destination du milieu geek "conditionné" (i.e qui comprend ce qu'est un float). Python n'est pas une calculatrice. Mais de toute façon, toute personne qui a déjà utilisé sa calculatrice est déjà habituée aux résultats approchés même pour des calculs évidents du genre 3 * 1/3 = 1 et ça ne fait pas sourire. Elle se rend juste compte qu'une machine qui ne gère que du fini, ne peut gérer exactement les nombres: elle ne peut faire, quasiment à chaque fois, que des approximations.
Non. Une calculatrice de base "se trompe" sur 1.000 000 1 * 0.999 999 9 qui sont deux décimaux très "raisonnables". Elle "se trompe" quasiment sur tous les calculs impliquant les décimaux (en fait la probabilité qu'une calculatrice donne un résultat juste dès qu'elle fait des multiplications ou divisions sur des décimaux aléatoires est de moins d'un milliardième (si on considère une machine sachant gérer 13 chiffres de mantisse).
En fait, bc fait
01:53:35 ~: bc
bc 1.07.1
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
1.01*0.99
.99
C'est à dire un résultat faux. Alors oui, tu peux évidemment pousser la mantisse utilisée par bc un peu plus si tu es "conditionné" aux problèmes que pose le calcul numérique sur une machine, mais tu tomberas sur le même problème un tout petit peu plus loin.
On peut, modulo des coûts de calcul très importants, colmater quelques erreurs (une sur un milliard environ) mais on ne peut pas régler le problème tout court. Il y aura toujours des calculs quasi évidents qui ne seront pas correctement effectués par une machine.
Tout comme ça m'a interpellé quand j'ai vu que presque tous les calculs faits par une calculatrice sont faux (sauf pour quelques opérations sur certains décimaux qui donnent une illusion d'exactitude au néophyte)
Il a tronqué un résultat faux au moment de l'affichage et qui du coup redonne une impression d'exactitude du calcul (il arrondit un arrondi faux qui redonne un résultat "exact" )
Non. Ça fait les mêmes bêtises, puis ça les cache avec des algos qui tentent de prédire ce que veut probablement l'utilisateur (en fonction de la configuration de l'arrondi dans le format de cellule). Calc utilise des floats derrière ton dos, fait, comme toute machine, les mêmes approximations, puis formate l'affichage pour qu'avec certains décimaux tu aies l'illusion que son calcul est juste, ce qui, évidemment, n'est pas vrai dans presque tous les cas.
En fait, il n'y a pas vraiment de problème:
Bref, on a une solution informatique convenable à quasiment tous les problèmes numériques usuels en fonction de chaque besoin spécifique.
Les sciences (mathématique/informatique) ont fait depuis longtemps le tour théorique de cette question en délimitant (démonstration à l'appui) précisément ce qu'on peut faire et ce que l'on ne peut pas faire, ce qu'il est intéressant de faire ou ce qu'il faut éviter de faire dans le domaine de la représentation des nombres en machine.
Tout cela a déjà été dit, dans les posts au dessus, mais certaines incompréhensions ayant nécessité beaucoup d'explications ont fini par noyer les messages très clairs donnés par beaucoup d'intervenants.
Les incompréhensions, quand on creuse un peu, viennent de représentations erronées de la nature même des nombres. Ce n'est pas étonnant car ces concepts sont en fait loin d'être évidents à comprendre surtout quand on croit (sincèrement) les maîtriser.