Maintenant, sachant que Perl6 répond à ton besoin tu devrais t’y mettre
Je reste simplement factuel. Le journal (pour y revenir) parle d'une soustraction dans Python. Je dis ça fait tache, je me fais incendier. J'ai mis 3 jours, mais je pense qu'on peut le dire clairement : oui, ça fait tache (source : les créateurs de Python eux-même)
CQFD.
Mes goûts perso n'ont rien à voir là dedans. Pas facile de rester factuel au post initial du journal. Une simple soustraction en Python et on en est venu à me parler de théorie analytique, d'ordinateurs quantiques, de la pollution humaine, de la granularité de l'espace temps…
Python, une soustraction, je n'ai pas démordu de ça.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Alors ouvrons tous ensemble notre esprit, et demandons-nous comment faire !
Comment fait Perl par exemple ? Pas de typage dynamique, ils gardent leur rationnal tout le temps et laissent "float" seulement à ceux qui l'ont explicité ? C'est une autre possibilité. Je sais pas… mais ne coupons pas court à toute discussion du moment qu'on n'a pas TOUS les détails techniques réglés.
L'idée de la discussion c'est :
- ne pas faire de calculs exacts sur des opérations de CE2, ça fait tache oui ou non (j'ai sorti des patchs Python et un fil de conversation qui prouve que les concepteurs de Python pensent que oui)
- a-t-on des solutions techniques pour le faire oui ou non (Perl l'a fait, on peut réfléchir à Python)
- quel est l'intérêt de le faire (j'ai tout simplement parlé de calculs exacts, c'est suffisant pour moi. autrement dit, c'est pour effacer la tache qui est globalement acceptée - voir ci-dessus)
- quel est l'inconvénient de le faire : les perfos (j'attends toujours un autre contre-argument pour ma part)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
en calcul scientifique on ne sait en général que faire du calcul approché
Si tu étais passé par le CE2 (au lieu de partir direct en Mat'Sup), tu saurais qu'il existe aussi des calculs simples qu'on peut faire exactement.
Je pense que c'est le rôle d'un langage généraliste comme Python de le proposer TANT QUE C'EST POSSIBLE, par exemple dans la soustraction dont parle le sujet du journal (pour y revenir encore et encore…)
Passer de "Decimal" à "float" automatiquement dès que le besoin s'en fait sentir (par exemple lorsque un scientifique veut calculer la distance Terre / Alpha du Centaure avec des allumettes) permet de tenir l'exact si c'est possible (et éviter ce que je considère ici comme anormal : 2.0 - 1.8 - 0.2 == 0.0 => False) et permet aussi aux scientifiques de faires des trucs 'achement balaises, toujours avec le même langage. GENERALISTE je dis.
Je ne veux pas éradiquer IEEE-754, je voudrais qu'on ne l'utilise que quand il est vraiment nécessaire. En dernier recours. Que ce ne soit pas le reflexe de "chiffre à virgule => float IEEE-754". D'autres implémentations existent. Et elles ne font pas d'erreur de calcul sur une soustraction de CE2.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Dans ce type de sujet, un truc qui me choque profondément c'est la main mise sur l'assemblée. Les députés LREM (en large majorité donc) n'ont pas le droit de voter autre chose que ce que donne le gouvernement, et n'ont pas le droit de ne pas voter ce que donne le gouvernement.
Mais on peut pas lui faire tous les reproches non plus : il a été élu en toutes connaissances de causes vu qu'il a déclaré en Janvier (avant son élection donc) : «Chaque candidat qui sera investi signera avec moi le contrat avec la nation. C’est-à-dire qu’il s’engage à voter à mes côtés les grands projets, c’est-à-dire à soutenir notre projet. Il n’y a pas de frondeurs […]. Il n’y a pas d’opportunisme, il n’y a pas des gens qui peuvent être investis en disant "eh bien moi, sur le cœur de votre projet […] je ne suis pas d’accord, je ne le voterai pas". C’est ce qu’on vit depuis vingt ans.»
Cumulé à l'alignement du quinquennat Présidentiel avec celui des députés, c'est carte blanche officielle pendant 5 ans.
Bravo le rôle de contrôle et de contre-pouvoir de l'assemblée (qui on le rappelle est la seule capable de renverser le gouvernement). C'est complètement anticonstitutionnel.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Même si c'est en sommeil (divesres raisons, la perfo en tête bien évidemment), je préfère déduire de ce post que mon idée n'est finalement pas si con que ça, et m'en tenir là. Mais comme c'est moi qui juge avec l'intelligence que j'ai… pitié, laissez-moi dans ma crédulité.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Surtout que comm te fait 3 colonnes (seulement dans fichier1, seulement dans fichier2, commun). Ensuite pour filtrer et en sortir des fichiers distinct… va falloir sortir awk :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
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.
Pour 99,9% du code sur cette planète (chiffre de mon doigt mouillé), qu’une boucle s’exécute en 1ms au lieu de 10ms n’est absolument pas un critère qui pèse dans le choix du langage…
Merci c'est un bon argument pour justifier que Python pourrait utiliser Decimal au lieu de float par défaut pour les litéraux :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Ah au fait, je t'ai pas remercié pour cette intervention, je le fais maintenant : merci :)
Qu'est que j'ai pris dans la gueule en attendant… Entre ceux qui démontrent que c'est pas possible, ceux qui disent que c'est une hérésie, ceux qui annoncent l'apocalypse et ceux qui me disent que je ferais mieux de prendre une calculette pour faire une soustraction aussi simple…
Alors qu'il suffisait de chercher ceux qui (inévitablement… c'est tellement ridicule une telle erreur dans une soustraction de CE2) s'étaient posé la même question avant.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Donc à la 17 ème décimale près et non à la 1ère décimale comme tu l'affirmes encore après 100 posts.
Faut être précis avec toi, mais tu as raison. IEEE-754 se vautre dans la représentation d'un nombre à 1 décimale : 0.1 par exemple. Mais 17 décimales, toi qui aimes la précision, ça devrait te frustrer non ? Je propose (depuis le début) Decimal qui non seulement ne ferait pas d'erreur sur 0.1, mais qui sur 1/3 tape dans les 28 décimales sans erreur. Ou mieux, Rationnal qui permet de ne pas approximer 1/3.
Tu préfères pas cette exactitude ? Moi si. Et les anneaux aussi je crois.
Ce truc ne choque que ceux qui ne comprennent pas comment calcule un ordinateur.
Et toi ce que tu ne veux pas comprendre, c'est qu'un ordinateur c'est le langage (disons le compilateur) (disons le langage machine… bon je te fais pas le détail) qui décide comment il calcule. Il n'est écrit nulle part que pour représenter "un chiffre à virgules" il faille absolument et uniquement utiliser IEEE-754. Faire une erreur de soustraction de CE2 je trouve ça ridicule. Donc je propose simplement qu'il change son mode de calcul dans le cadre d'un langage généraliste comme Python.
Ca permettra d'éviter des erreurs sur 2.0 - 1.8 - 0.2 (exemple au hasard bien sûr)
on lui offre une calculatrice
Ou Perl, ou l'une des prochaines versions de Python (j'insiste, parce que t'as l'air de continuer à affirmer que mon idée est une idée à la con)
et là il s'interroge pourquoi 2/3 se termine par un 7
Pas si il utilise Perl. Ou peut-être une prochaine version de Python (Decimal ou Rationnal ? A voir). Il sera content de voir que utiliser un langage moderne permet des choses sympa.
puis il se dit que l'exactitude sur une calculatrice est une illusion.
L'exactitude dans tous les cas, oui c'est une illusion, tu m'as déjà expliqué que des scientifiques super intelligents (bcp plus que moi en tous cas) avaient démontré qu'on n'arriverait pas à tout représenter dans une calculatrice (ni dans un float d'ailleurs). Mais dans le cas de 2 - 1.8 - 0.2, au moins, la calculatrice elle se trompe pas (les même scientifiques sont formels). Tu trouves pas que c'est un peu con que Python se trompe sur cette soustraction alors que la calculatrice se trompe pas ?
Ah pardon, la calculatrice soustrait, alors que Python approxime à … merde je retrouve plus la formule.
Bref, je trouve que ça fait tache.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Et donc si ça se vautre à partir de la 28ème décimale c'est pas grave mais à la 17ème c'est horrible.
Oui. Pour rappel, la sitaution actuelle, float, se vautre dès la première.
Tu n'as qu'à bosser avec des floats sur 128bits en IEEE754 comme ça, tu gagneras sur tous les plans
Non. On ne pourra toujours pas représenter exactement 0.1 et surtout 2 - 1.8 - 0.2 continuera à retourner autre chose que zéro (ce qui est l'objet du journal, je le rappelle encore une fois, mais t'écoutes rien)
Et pour ton problème d'affichage des décimaux
Mon problème c'est pas l'affichage, c'est le calcul mathématique (tu sais le truc avec les anneaux).
Ah bah oui, la voilà la révolution, on se met en BCD comme sur les calculatrices depuis les années 70
C'est une possiblité qui m'irait. Mais depuis la recherche a fait quelques progrès, par exemple Decimal. Ne dénigre pas stp les avancées des scientifiques.
Mais évidemment pour autre chose que 1/10 ça plantera
Le rationnal est une autre possibilité qui m'irait bcp et qui ouvrirait sur le fameux 1/3 que tu ne peux pas te sortir de la tête (et que je n'ai jamais revendiqué).
Mais tu sors du cadre du journal où on parle de soustractions et de calculs de CE2 (ça c'est moi qui est tenté de généraliser le pb du journal). En CE2 on n'essaie pas de représenter des rationnels non décimaux par des représentation décimales.
Les décimaux c'est tellement important quand on fait des calculs. Pas de tiers
1/3 c'est pas représentable en float non plus.
multiplier les coûts de calcul par 50
Tu le sors de quel chapeau ? Perl a fait ce choix (et même plus chaud : rationnal), Python a parlé de le faire (j'ai le lien sous le coude je rappelle), tu iras leur dire qu'ils font n'importe quoi.
consommer des mégawatts dans le monde entier
Le SIDA c'est pas moi, je promets.
à moins qu'on ne se contente d'arrondir la sortie utilisateur au décimal le plus proche non ?
Non. Je veux (2.0 - 1.8 - 0.2 == 0.0) => True (ça aussi je l'ai dit et répété)
C'est le choix de ton tableur, utiliser des floats et arrondir pour entretenir l'illusion :)
C'est peut-être leur choix, mais c'est pas certain. Je ne serais pas si sûr si j'étais toi (mais bon, t'es un mec vachement sûr de lui aussi). Pour rappel un tableur n'est pas spécialiste de gros calculs mais de calculs destinées à être affichés à l'utilisateur. En tous cas, c'est pas le choix que je ferais. Mais j'ai des idées à la con aussi. (cherche pas l'implémentation de LibreOffice, on s'en branle, c'est juste pour te faire chier)
Bon alors si tu veux savoir pourquoi on bosse en base 2 avec des float et non en base 10 avec le format BCD, c'est tout simplement parce que si tu veux stocker un chiffre en base 10 il te faut minimum 4 bits alors qu'avec 4 bits tu pourrais stocker 16 nombres différents.
Oui, et parce que ça va bcp plus vite. Je sais tout ça, t'inquiètes pas.
On pourrait aussi ajouter qu'en algorithmique il est ultra fréquent de diviser par 2 (ne serait-ce que pour tous les algos dichotomiques). alors que diviser par 10 n'est utile que pour des sorties utilisateur décimales….
Alors je te spoile : la valeur de départ que tu as toi-même utilisé, je peux la diviser par 2, encore la diviser par 2, et faire ça des dizaines de fois, je serai toujours en valeur exacte. Toi, tu ne m'as toujours pas dit si ta valeur de départ était déjà représentable en IEEE-754. Par contre je suis d'accord ça ira moins vite, mais ça aussi je l'ai déjà dit un paquet de fois.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
alors que tu prétends que la communauté scientifique n'a pas assez progressé à ton goût
Dis-moi où j'ai dis ça simplement en revendiquant haut et fort qu'un langage comme Python devrait être capable par défaut d'effectuer 2 - 1.8 - 0.2 sans erreur de calcul. Je n'ai jamais rien dit d'autre dans mes posts.
Tu penses depuis le début que je veux tout représenter parfaitement. Je n'ai jamais parlé de ça. J'ai parlé de maths de CE2. J'ai dis que la moindre des choses, c'est qu'un langage comme Python ne se vautre pas sur des maths de CE2.
Pour cela, il suffirait d'activer Decimal par défaut lors de la déclaration de litéraux par exemple. C'est tout. Pour ma part je suis toujours resté sur le problème posé par le titre de ce journal :
>>>2-1.8-0.2-5.551115123125783e-1
C'est moche, ça fait tache.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
J'ai toujours dit que j'étais bien conscient que Decimal était limité à 28 chiffres après la virgule (c'est dans la doc), tu me donnes un exemple à 30 chiffres après la virgule, donc ça fait pas trop avancer le shmilblick
Là tu es limité par l'affichage, demande la totalité de la représentation interne par repr() (faudrait lire la doc un peu) et tu verras tes 28 décimales (float à côté c'est de la gnognotte)
Decimal a la decence de te garantir que 1.23456789987654 sera exactement représenté, alors que IEEE-754 ne te le garantie pas (si tu es si fort, dis-moi si c'est le cas) (et bien sûr je veux l'explication, trop facile de tester). C'est plutôt ça qui me choque à la base.
Une fois ce chiffre saisi et correctement stocké en mémoire (c'est pas le boulot d'un ordi ça à la base ?) je sais ce que je peux y faire dessus sans perdre de précision (je peux t'affirmer que je peux le diviser encore par 10, je sais que le résultat sera exact. Promis. Tu peux en dire autant en float ?
Ton exemple a généré un signal te disant que ce n'est plus exact, tu aurais pu l'utiliser (mais faut avoir lu la doc avant)
Mais surtout : 0.1, en décimal, c'est possible et c'est l'objet de ce journal (et rien d'autre)
En échange de tous ces avantages de Decimal, peux(tu me donner un seul avantage de faire le même calcul en float, autre que la rapidité ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Petit résumé et tests dans la réalité
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à 0.
Il est amusant ton bench.
Et essaie de l'exécuter avec /usr/bin/python3 , c'est encore plus amusant tu verras :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Petit résumé et tests dans la réalité
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à 0.
Ouais, t'as raison, en fait c'était une mauvaise idée.
Merci !
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.
Et tu prends +1 avec une magnifique démonstration que 300/6 != 50/9
Les mecs, vous êtes risibles.
Mais une fois corrigé, en Perl, ça marche. Donc de Decimal passons à Rationnal par défaut, oui, pourquoi pas (je l'ai aussi dit 500x mais oublions).
Mais de toutes façons on sort du CE2 et des soustractions (sujet du journal, vous divergez).
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é à -2.
Ca, tu peux le dire :)
Oh ça je m'en doute bien.
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.
C'est ton avis et pas le mien. Ni celui du créateur Python. Du coup je me sens un poil plus en position de force depuis que j'ai trouvé ça.
Après je suis étonné que celui qui me bassinait avec les corps et les anneaux ne comprenne pas l'intérêt de calculs justes par exemple.
Accessoirement, ça évite des comportements comme "2.0 - 1.8 - 0.0 == 0.0" => False.
On a beau avoir l'explication technique derrière… c'est con, ça fait tache.
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.
Si tu lis la feuille de route de GvR, ils y ont pensé. Ils ont une certaine expérience en matière d'incompatibilité.
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é à -2.
Génial, merci :)
Une brique de plus : à la base c'est pas con, c'est même la tendance actuelle.
Une petite pensée pour les 9/10e des posts tentant de me convaincre de l'inverse, voire que c'est carrément pas possible.
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.
http://linuxfr.org/users/reynum/journaux/humour-vers-un-monde-different#comment-1724770
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Pourquoi calculer en virgule flottante?
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -1.
Je reste simplement factuel. Le journal (pour y revenir) parle d'une soustraction dans Python. Je dis ça fait tache, je me fais incendier. J'ai mis 3 jours, mais je pense qu'on peut le dire clairement : oui, ça fait tache (source : les créateurs de Python eux-même)
CQFD.
Mes goûts perso n'ont rien à voir là dedans. Pas facile de rester factuel au post initial du journal. Une simple soustraction en Python et on en est venu à me parler de théorie analytique, d'ordinateurs quantiques, de la pollution humaine, de la granularité de l'espace temps…
Python, une soustraction, je n'ai pas démordu de ça.
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é à -2.
Alors ouvrons tous ensemble notre esprit, et demandons-nous comment faire !
Comment fait Perl par exemple ? Pas de typage dynamique, ils gardent leur rationnal tout le temps et laissent "float" seulement à ceux qui l'ont explicité ? C'est une autre possibilité. Je sais pas… mais ne coupons pas court à toute discussion du moment qu'on n'a pas TOUS les détails techniques réglés.
L'idée de la discussion c'est :
- ne pas faire de calculs exacts sur des opérations de CE2, ça fait tache oui ou non (j'ai sorti des patchs Python et un fil de conversation qui prouve que les concepteurs de Python pensent que oui)
- a-t-on des solutions techniques pour le faire oui ou non (Perl l'a fait, on peut réfléchir à Python)
- quel est l'intérêt de le faire (j'ai tout simplement parlé de calculs exacts, c'est suffisant pour moi. autrement dit, c'est pour effacer la tache qui est globalement acceptée - voir ci-dessus)
- quel est l'inconvénient de le faire : les perfos (j'attends toujours un autre contre-argument pour ma part)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Élection de Castaner
Posté par gUI (Mastodon) . En réponse au journal Le changement c'est maintenant ;). Évalué à 6.
Tu as raison.
Je parlais selon le réglement intérieur de LREM et le contrat qu'ils ont signé. Disons "ils se sont engagés à".
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é à -3.
Entièrement d'accord.
http://linuxfr.org/users/reynum/journaux/humour-vers-un-monde-different#comment-1724453
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.
Si tu étais passé par le CE2 (au lieu de partir direct en Mat'Sup), tu saurais qu'il existe aussi des calculs simples qu'on peut faire exactement.
Je pense que c'est le rôle d'un langage généraliste comme Python de le proposer TANT QUE C'EST POSSIBLE, par exemple dans la soustraction dont parle le sujet du journal (pour y revenir encore et encore…)
Passer de "Decimal" à "float" automatiquement dès que le besoin s'en fait sentir (par exemple lorsque un scientifique veut calculer la distance Terre / Alpha du Centaure avec des allumettes) permet de tenir l'exact si c'est possible (et éviter ce que je considère ici comme anormal : 2.0 - 1.8 - 0.2 == 0.0 => False) et permet aussi aux scientifiques de faires des trucs 'achement balaises, toujours avec le même langage. GENERALISTE je dis.
Je ne veux pas éradiquer IEEE-754, je voudrais qu'on ne l'utilise que quand il est vraiment nécessaire. En dernier recours. Que ce ne soit pas le reflexe de "chiffre à virgule => float IEEE-754". D'autres implémentations existent. Et elles ne font pas d'erreur de calcul sur une soustraction de CE2.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: chargeons la barque
Posté par gUI (Mastodon) . En réponse au journal Le changement c'est maintenant ;). Évalué à 1.
Certes c'est une vaste question, mais au moins c'est cohérant avec ce qui lui affirme de manière générale. C'est l'inverse que je trouverais anormal.
Un politique qui applique à lui-même ce qu'il préconise, c'est pas tous les jours :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Élection de Castaner
Posté par gUI (Mastodon) . En réponse au journal Le changement c'est maintenant ;). Évalué à 10.
Dans ce type de sujet, un truc qui me choque profondément c'est la main mise sur l'assemblée. Les députés LREM (en large majorité donc) n'ont pas le droit de voter autre chose que ce que donne le gouvernement, et n'ont pas le droit de ne pas voter ce que donne le gouvernement.
Mais on peut pas lui faire tous les reproches non plus : il a été élu en toutes connaissances de causes vu qu'il a déclaré en Janvier (avant son élection donc) :
«Chaque candidat qui sera investi signera avec moi le contrat avec la nation. C’est-à-dire qu’il s’engage à voter à mes côtés les grands projets, c’est-à-dire à soutenir notre projet. Il n’y a pas de frondeurs […]. Il n’y a pas d’opportunisme, il n’y a pas des gens qui peuvent être investis en disant "eh bien moi, sur le cœur de votre projet […] je ne suis pas d’accord, je ne le voterai pas". C’est ce qu’on vit depuis vingt ans.»
Cumulé à l'alignement du quinquennat Présidentiel avec celui des députés, c'est carte blanche officielle pendant 5 ans.
Bravo le rôle de contrôle et de contre-pouvoir de l'assemblée (qui on le rappelle est la seule capable de renverser le gouvernement). C'est complètement anticonstitutionnel.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Pourquoi calculer en virgule flottante?
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à 1.
En tous cas, côté Python, ils y ont pensé.
Même si c'est en sommeil (divesres raisons, la perfo en tête bien évidemment), je préfère déduire de ce post que mon idée n'est finalement pas si con que ça, et m'en tenir là. Mais comme c'est moi qui juge avec l'intelligence que j'ai… pitié, laissez-moi dans ma crédulité.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: comm
Posté par gUI (Mastodon) . En réponse au message Créer deux fichiers avec un seul grep. Évalué à 1.
Surtout que
commte fait 3 colonnes (seulement dans fichier1, seulement dans fichier2, commun). Ensuite pour filtrer et en sortir des fichiers distinct… va falloir sortir awk :)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é à -3.
Là tu ne m'as pas du tout déçu. J'ai compris maintenant pourquoi ce thread ne s'arrêtera jamais.
J'espère que tes étudiants ne tomberont pas sur cette phrase.
Ca fait tache…
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.
[^] # Re: Pourquoi calculer en virgule flottante?
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -4.
Merci c'est un bon argument pour justifier que Python pourrait utiliser Decimal au lieu de float par défaut pour les litéraux :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Rien de surprenant
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -1.
Ah au fait, je t'ai pas remercié pour cette intervention, je le fais maintenant : merci :)
Qu'est que j'ai pris dans la gueule en attendant… Entre ceux qui démontrent que c'est pas possible, ceux qui disent que c'est une hérésie, ceux qui annoncent l'apocalypse et ceux qui me disent que je ferais mieux de prendre une calculette pour faire une soustraction aussi simple…
Alors qu'il suffisait de chercher ceux qui (inévitablement… c'est tellement ridicule une telle erreur dans une soustraction de CE2) s'étaient posé la même question avant.
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é à -5.
Faut être précis avec toi, mais tu as raison. IEEE-754 se vautre dans la représentation d'un nombre à 1 décimale : 0.1 par exemple. Mais 17 décimales, toi qui aimes la précision, ça devrait te frustrer non ? Je propose (depuis le début) Decimal qui non seulement ne ferait pas d'erreur sur 0.1, mais qui sur 1/3 tape dans les 28 décimales sans erreur. Ou mieux, Rationnal qui permet de ne pas approximer 1/3.
Tu préfères pas cette exactitude ? Moi si. Et les anneaux aussi je crois.
Et toi ce que tu ne veux pas comprendre, c'est qu'un ordinateur c'est le langage (disons le compilateur) (disons le langage machine… bon je te fais pas le détail) qui décide comment il calcule. Il n'est écrit nulle part que pour représenter "un chiffre à virgules" il faille absolument et uniquement utiliser IEEE-754. Faire une erreur de soustraction de CE2 je trouve ça ridicule. Donc je propose simplement qu'il change son mode de calcul dans le cadre d'un langage généraliste comme Python.
Ca permettra d'éviter des erreurs sur 2.0 - 1.8 - 0.2 (exemple au hasard bien sûr)
Ou Perl, ou l'une des prochaines versions de Python (j'insiste, parce que t'as l'air de continuer à affirmer que mon idée est une idée à la con)
Pas si il utilise Perl. Ou peut-être une prochaine version de Python (Decimal ou Rationnal ? A voir). Il sera content de voir que utiliser un langage moderne permet des choses sympa.
L'exactitude dans tous les cas, oui c'est une illusion, tu m'as déjà expliqué que des scientifiques super intelligents (bcp plus que moi en tous cas) avaient démontré qu'on n'arriverait pas à tout représenter dans une calculatrice (ni dans un float d'ailleurs). Mais dans le cas de 2 - 1.8 - 0.2, au moins, la calculatrice elle se trompe pas (les même scientifiques sont formels). Tu trouves pas que c'est un peu con que Python se trompe sur cette soustraction alors que la calculatrice se trompe pas ?
Ah pardon, la calculatrice soustrait, alors que Python approxime à … merde je retrouve plus la formule.
Bref, je trouve que ça fait tache.
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é à -5.
Oui. Pour rappel, la sitaution actuelle, float, se vautre dès la première.
Non. On ne pourra toujours pas représenter exactement 0.1 et surtout 2 - 1.8 - 0.2 continuera à retourner autre chose que zéro (ce qui est l'objet du journal, je le rappelle encore une fois, mais t'écoutes rien)
Mon problème c'est pas l'affichage, c'est le calcul mathématique (tu sais le truc avec les anneaux).
C'est une possiblité qui m'irait. Mais depuis la recherche a fait quelques progrès, par exemple Decimal. Ne dénigre pas stp les avancées des scientifiques.
Le rationnal est une autre possibilité qui m'irait bcp et qui ouvrirait sur le fameux 1/3 que tu ne peux pas te sortir de la tête (et que je n'ai jamais revendiqué).
Mais tu sors du cadre du journal où on parle de soustractions et de calculs de CE2 (ça c'est moi qui est tenté de généraliser le pb du journal). En CE2 on n'essaie pas de représenter des rationnels non décimaux par des représentation décimales.
1/3 c'est pas représentable en float non plus.
Tu le sors de quel chapeau ? Perl a fait ce choix (et même plus chaud : rationnal), Python a parlé de le faire (j'ai le lien sous le coude je rappelle), tu iras leur dire qu'ils font n'importe quoi.
Le SIDA c'est pas moi, je promets.
Non. Je veux (2.0 - 1.8 - 0.2 == 0.0) => True (ça aussi je l'ai dit et répété)
C'est peut-être leur choix, mais c'est pas certain. Je ne serais pas si sûr si j'étais toi (mais bon, t'es un mec vachement sûr de lui aussi). Pour rappel un tableur n'est pas spécialiste de gros calculs mais de calculs destinées à être affichés à l'utilisateur. En tous cas, c'est pas le choix que je ferais. Mais j'ai des idées à la con aussi. (cherche pas l'implémentation de LibreOffice, on s'en branle, c'est juste pour te faire chier)
Oui, et parce que ça va bcp plus vite. Je sais tout ça, t'inquiètes pas.
Alors je te spoile : la valeur de départ que tu as toi-même utilisé, je peux la diviser par 2, encore la diviser par 2, et faire ça des dizaines de fois, je serai toujours en valeur exacte. Toi, tu ne m'as toujours pas dit si ta valeur de départ était déjà représentable en IEEE-754. Par contre je suis d'accord ça ira moins vite, mais ça aussi je l'ai déjà dit un paquet de fois.
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. Dernière modification le 21 décembre 2017 à 20:21.
Dis-moi où j'ai dis ça simplement en revendiquant haut et fort qu'un langage comme Python devrait être capable par défaut d'effectuer 2 - 1.8 - 0.2 sans erreur de calcul. Je n'ai jamais rien dit d'autre dans mes posts.
Tu penses depuis le début que je veux tout représenter parfaitement. Je n'ai jamais parlé de ça. J'ai parlé de maths de CE2. J'ai dis que la moindre des choses, c'est qu'un langage comme Python ne se vautre pas sur des maths de CE2.
Pour cela, il suffirait d'activer Decimal par défaut lors de la déclaration de litéraux par exemple. C'est tout. Pour ma part je suis toujours resté sur le problème posé par le titre de ce journal :
C'est moche, ça fait tache.
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é à -3.
T'en redemandes ? Allons-y doucement…
Ton exemple a généré un signal te disant que ce n'est plus exact, tu aurais pu l'utiliser (mais faut avoir lu la doc avant)
Mais surtout : 0.1, en décimal, c'est possible et c'est l'objet de ce journal (et rien d'autre)
En échange de tous ces avantages de Decimal, peux(tu me donner un seul avantage de faire le même calcul en float, autre que la rapidité ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.