Mais tu n'as toujours pas lu que ce n'est pas vrai ??? La preuve:
Oui, je m'ai trompé, je l'ai dit dans l'autre, on a croisé les conversations. IEEE se trompe sur la représentation d'un décimal qui a un chiffre après la virgule. Pardon. Mais l'erreur sur 0.1 est plus petite que 1/10, c'est une bonne nouvelle.
Bah non, ton problème c'est l'affichage du résultat
Je suis pas fan quand tu me dis ce que je pense, surtout quand c'est pas ça.
J'en sais rien pour les tableurs, c'est pas trop le sujet ici. Si tu fais 2.0 - 1.8 - 0.2 == 0, il te dit VRAI ton tableur ? Si oui, il me va très bien. Si non, c'est le même combat en effet. Je ne pense pas que ce soit de l'affichage. Je te parle exactitude, tu me réponds affichage. C'est pénible.
Par contre certains en avaient marre en effet des pb d'affichage dont tu parles et ont ajouté du code (chacun jugera de l'élégance) pour cacher la misère de IEEE-754 : https://bugs.python.org/issue1580 (j'ai déjà donné ce lien, mais je ne suis pas sûr que tu sois allé voir).
Bah oui ça tombe bien parce qu'on fout vu que ça reviendrait à vouloir que les 1/n soient tous représentables exactement en machine ce qui n'est pas possible dans une base donnée.
Pour peux que n soit représentable raisonnablement (style un entier sur 64 bits, c'est déjà pas mal, on en trouve des n), si, on peut le représenter en machine. Facilement en plus. Et sans erreur. Le type Rationnal existe pour ça. Ensuite en BdD je sais pas (qu'estce que ça vient foutre là ?), mais c'est pas le sujet ici, on parle de Python et de soustractions. (t'es agaçant à vouloir tout généraliser pour ensuite démontrer que tout n'est pas généralisable).
On va compter si tu veux.
Non, épargne-moi ça stp. Demande plutôt à Perl ce qu'ils en pensent, eux qui ont fait ce choix . Il me semble même qu'il y a un lien dans cette page...
Bah si c'est certain.
Un très bon point pour toi !!! On peut revenir maintenant à Python et sa soustraction à 1 décimale avec un résultat faux ?
Pourquoi je dirais un truc comme ça puisque ça n'a aucune espèce d'importance ?
Tu ne vas pas renier les anneaux quand même ? Après m'avoir bassiné par l'analyse et les grandes théories, tu vas maintenant me dire que... boarf... 0.1... finalement qu'est-ce que c'est ? Qui ça intéresse ? Du moment que c'est à 10-17 près... ça suffit non ?
Je reviens à ce que je dis : s'il-te-plait, donne moi un avantage du float par rapport au Decimal mis à part la perfo.
Si ça ne l'est pas exactement en interne, je formaterai (si j'en avais besoin) la sortie utilisateur pour que ce soit joliment arrondi et c'est tout.
Si ça ne l'est pas en interne, il y audra des erreurs de calcul derrière. L'anneau, il veut pas ça.
Tu te limites au print, mais n'oublie pas : 2.0 - 1.8 - 0.2 == 0.0 => False
Je trouve que ça fait tache dans un langage moderne généraliste.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Puisque tout le monde est sûr de détenir la vérité...
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -4.
Oui, je m'ai trompé, je l'ai dit dans l'autre, on a croisé les conversations. IEEE se trompe sur la représentation d'un décimal qui a un chiffre après la virgule. Pardon. Mais l'erreur sur 0.1 est plus petite que 1/10, c'est une bonne nouvelle.
Je suis pas fan quand tu me dis ce que je pense, surtout quand c'est pas ça.
J'en sais rien pour les tableurs, c'est pas trop le sujet ici. Si tu fais 2.0 - 1.8 - 0.2 == 0, il te dit VRAI ton tableur ? Si oui, il me va très bien. Si non, c'est le même combat en effet. Je ne pense pas que ce soit de l'affichage. Je te parle exactitude, tu me réponds affichage. C'est pénible.
Par contre certains en avaient marre en effet des pb d'affichage dont tu parles et ont ajouté du code (chacun jugera de l'élégance) pour cacher la misère de IEEE-754 : https://bugs.python.org/issue1580 (j'ai déjà donné ce lien, mais je ne suis pas sûr que tu sois allé voir).
Pour peux que n soit représentable raisonnablement (style un entier sur 64 bits, c'est déjà pas mal, on en trouve des n), si, on peut le représenter en machine. Facilement en plus. Et sans erreur. Le type Rationnal existe pour ça. Ensuite en BdD je sais pas (qu'estce que ça vient foutre là ?), mais c'est pas le sujet ici, on parle de Python et de soustractions. (t'es agaçant à vouloir tout généraliser pour ensuite démontrer que tout n'est pas généralisable).
Non, épargne-moi ça stp. Demande plutôt à Perl ce qu'ils en pensent, eux qui ont fait ce choix . Il me semble même qu'il y a un lien dans cette page...
Un très bon point pour toi !!! On peut revenir maintenant à Python et sa soustraction à 1 décimale avec un résultat faux ?
Tu ne vas pas renier les anneaux quand même ? Après m'avoir bassiné par l'analyse et les grandes théories, tu vas maintenant me dire que... boarf... 0.1... finalement qu'est-ce que c'est ? Qui ça intéresse ? Du moment que c'est à 10-17 près... ça suffit non ?
Je reviens à ce que je dis : s'il-te-plait, donne moi un avantage du float par rapport au Decimal mis à part la perfo.
Si ça ne l'est pas en interne, il y audra des erreurs de calcul derrière. L'anneau, il veut pas ça.
Tu te limites au print, mais n'oublie pas : 2.0 - 1.8 - 0.2 == 0.0 => False
Je trouve que ça fait tache dans un langage moderne généraliste.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.