Je comprends que l'ambiance se dégrade très vite ici. Je vais juste l'écrire paisiblement : commentaire inutile.
a) contexte mathématique numérique théorique et donc justement pas en implémentations informatiques "biaisées"
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).
Exception de valeurs particulière, données par B.Sibaud, qui avait bien compris/lu la remarque.
b) oui, et re-re-oui, on a tous compris l'explication mécanique. J'ai bien tout relu avant de commenter.
c) oui également, Decimal est effectivement un moyen de cacher/surcharger/contourner ce qui "tracasse"
d) exemple inutile. Pas d'étape pathologique inside. À comparer avec 0.2+0.4-0.6 et même avec 0.2-0.6-0.4, où l'erreur affichée n'est pas la même, non commutativité des calculs numériques [/ arrondis] bien connue également...
Fin, bref, ça tourne en rond, pour rien.
Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.
Perso je vois au moins trois implémentations arithmétiques "decimalo-flottantes" satisfaisantes (au sens naturel du terme)
* une simple calculatrice scientifique qui couvre correctement son domaine de fonctionnement (exact pour les décimaux usuels, notation ingénieur/scientifique ailleurs)
* bc, (An arbitrary precision calculator language) même caractéristiques
* le langage de Google, Go qui semble se comporter comme souhaité. (confirmation/infirmation ?)
Cela est donc bien possible. Que cela ne soit pas le choix de Python (et de bien d'autres langages), ben ok. Mais ça interpelle. C'est tout.
PS : Ah oui, en La(TeX) aussi c'est bon à première vue, 0.2+0.4 donne 0.60000 ;-)
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.
[^] # Re: Commentaire de soutien ;-)
Posté par C138 . En réponse au journal [Humour] vers un monde différent. Évalué à -3.
Je comprends que l'ambiance se dégrade très vite ici. Je vais juste l'écrire paisiblement : commentaire inutile.
a) contexte mathématique numérique théorique et donc justement pas en implémentations informatiques "biaisées"
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).
Exception de valeurs particulière, données par B.Sibaud, qui avait bien compris/lu la remarque.
b) oui, et re-re-oui, on a tous compris l'explication mécanique. J'ai bien tout relu avant de commenter.
c) oui également, Decimal est effectivement un moyen de cacher/surcharger/contourner ce qui "tracasse"
d) exemple inutile. Pas d'étape pathologique inside. À comparer avec 0.2+0.4-0.6 et même avec 0.2-0.6-0.4, où l'erreur affichée n'est pas la même, non commutativité des calculs numériques [/ arrondis] bien connue également...
Fin, bref, ça tourne en rond, pour rien.
Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.
Perso je vois au moins trois implémentations arithmétiques "decimalo-flottantes" satisfaisantes (au sens naturel du terme)
* une simple calculatrice scientifique qui couvre correctement son domaine de fonctionnement (exact pour les décimaux usuels, notation ingénieur/scientifique ailleurs)
* bc, (An arbitrary precision calculator language) même caractéristiques
* le langage de Google, Go qui semble se comporter comme souhaité. (confirmation/infirmation ?)
Cela est donc bien possible. Que cela ne soit pas le choix de Python (et de bien d'autres langages), ben ok. Mais ça interpelle. C'est tout.
PS : Ah oui, en La(TeX) aussi c'est bon à première vue, 0.2+0.4 donne 0.60000 ;-)
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.