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.
Non je ne pense pas. Cursus pur universitaire, même si j'ai fais mon DESS en "année de spécialisation INSA" (c'est pas des blagues).
Heureusement on m'a pas appris les anneau et les corps mais plutôt la microélectronique, le VHDL, les ASICs. On a même cablé un processeur RISC avec des portes logique (et des bascules je crois).
Après j'ai un côté idéaliste assez poussé j'avoue :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
D'ailleurs, ce nouveau standard, déjà documenté, fonctionne évidemment comme prévu (donc comme une calculatrice) et quand tu lui demandes 1.0000000001 * 0.999999999, il se vautre en sortant que ça fait 1, comme le float IEEE754
si il fait "2.0 - 1.8 - 0.2 = 0" (ce dont je ne doute pas), c'est déjà un pas dans MA direction
je ne parle même pas de ça, je parle du type Decimal où 1.0000000001 * 0.999999999 = 0.9999999990999999999 exactement, sans erreur d'arrondi d'aucune sorte. Des valeurs exactes sur des grandeurs ordinaires quoi (et même si là on sort de l'ordinaire, j'ai pas peur, Decimal est précis 28 chiffres après la virgule, on a de la marge avant de dire "ah tu vois on ne résoud pas tout !")
Je sais que c'est un choc pour toi, mais il y a des gens qui pensent comme moi : c'est con que Python fasse moins bien qu'une calculatrice sur des chiffres comme ça.
Au bout de 200 posts, c'est triste de ne toujours pas avoir été compris. Faut que je réexplique.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Quand tu auras accès intellectuellement à ces concepts, tu reliras ce fil, et tu te rendras compte de pas mal de choses (en particulier sur ta personnalité), et tu comprendras, j'espère, pourquoi tu as agacé autant de monde ici. Tant que tu ne le feras pas, tu resteras dans l'illusion.
T'es vraiment sûr de toi comme mec, c'est bien. Mais c'est risqué : t'as vraiment intérêt à avoir raison, sinon tu passes un peu pour un con.
Le jour où Python active le type Decimal par défaut sur les litéraux, il va y avoir du déterrage de post !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Mmmm… t'es bien sûr ? Non parce que comme c'est la 3e formule, je me dis que celle-ci est peut-être fausse…
Tout ça pour calculer une somme de 3 termes du CE2. Et quand je dis "tiens on pourrait utiliser un autre type que float pour représenter les litéraux par exemple" on me demande "mais pourquoi faire".
Voilà pourquoi.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Mis à part les perfos, je vois pas trop… ce qui va être dur à justifier pour un affichage de hall…
Si t'as besoin du Gigabit pour faire du streaming 4K, et encore, pas trop optimisé (j'ai qques démos 4K qui dépassent le 100Mb/s, mais en général, même les démos qui sont là pour faire joli sont de l'ordre de 30-40Mb/s)
Le "out of box", la qualité du SAV ?
Si pour 300€ ça juste marche dans ton hall que tu te sens pas trop à installer RPi sur une carte SD, trouver comment faire booter directement sous l'affichage qui va bien… pourquoi pas ?
Mais le public visé n'est dans tous les cas pas trop le geek de LinuxFR, je ne pense pas.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Et encore tu connais pas Pearl6. Il paraît qu'il est tellement lent que quand tu tapes 0.1 il a le temps de se le représenter exactement en mémoire. Ils auraient lu le Seigneur des Corps (ou des Anneaux je sais plus), ils auraient pas fait cette connerie monumentale.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
nous démontrons facilement que Python a décidé de privilégier la rapidité des calculs des fonctions de Bessel (ou des fonctions gamma d'Euler) plutôt que la justesse des soustractions à un chiffre après la virgule
De la tartine de posts je déduis donc qu'on peut rajouter :
c'est très bien comme ça, on voit pas pourquoi ça devrait changer
Merci à tous d'avoir participé.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
C'est un manque de recul mathématique qui te fait agir de la sorte.
Sûrement. Dis-moi c'est dans les anneaux ou les corps que tu justifies ce comportement actuel ?
>>>2.0-1.8-0.2==0.0False
Je ne comprends toujours pas comment tu peux argumenter l'utilisation de IEE-754 vs Decimal avec des théories mathématiques. Le float a pour lui énormément d'avantages, mais dès lors qu'on parle Mathématiques, il est quand même un peu un gros barbare.
Par exemple, Decimal te sors un signal dès lors qu'il sort de l'exactitude (class decimal.Inexact). Avec le type Decimal, tu sais que en calculant 1/10 tu as une valeur exacte, mais en calculant 1/3 tu n'auras qu'une approximation (10-28 par défaut au passage, le float se fait bien exploser). Perso je trouve ça un poil plus rigoureux.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
L'ensemble des nombres gérés par IEEE754 n'est ni un groupe, ni anneau, ni un corps.
Ok.
Je suppose que c'est pareil pour la représentation que propose le Decimal (je parlais du module Python que j'aime bcp, pas des décimaux dans le sens Mathématique D ).
Donc utiliser un type Decimal à la place d'un float n'apporte aucune regression sur ce plan-là.
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.
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.
[^] # 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é à -6.
Oui alors sur le chapitre… tu peux relire tout ce que tu as écris sur moi précédemment, c'est pas non plus joli-joli.
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é à -7.
Non je ne pense pas. Cursus pur universitaire, même si j'ai fais mon DESS en "année de spécialisation INSA" (c'est pas des blagues).
Heureusement on m'a pas appris les anneau et les corps mais plutôt la microélectronique, le VHDL, les ASICs. On a même cablé un processeur RISC avec des portes logique (et des bascules je crois).
Après j'ai un côté idéaliste assez poussé j'avoue :)
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é à -6.
Je sais que c'est un choc pour toi, mais il y a des gens qui pensent comme moi : c'est con que Python fasse moins bien qu'une calculatrice sur des chiffres comme ça.
Au bout de 200 posts, c'est triste de ne toujours pas avoir été compris. Faut que je réexplique.
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.
Heureusement qu'il est sous pseudo, parce que quand je vais sortir le post de GvR qui dit donne une feuille de route, ça va ricaner dans les classes.
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'es vraiment sûr de toi comme mec, c'est bien. Mais c'est risqué : t'as vraiment intérêt à avoir raison, sinon tu passes un peu pour un con.
Le jour où Python active le type Decimal par défaut sur les litéraux, il va y avoir du déterrage de post !
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.
Mmmm… t'es bien sûr ? Non parce que comme c'est la 3e formule, je me dis que celle-ci est peut-être fausse…
Tout ça pour calculer une somme de 3 termes du CE2. Et quand je dis "tiens on pourrait utiliser un autre type que float pour représenter les litéraux par exemple" on me demande "mais pourquoi faire".
Voilà pourquoi.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Intel NUC
Posté par gUI (Mastodon) . En réponse à la dépêche Le Linutop 6, le nouveau PC sans ventilateur. Évalué à 6. Dernière modification le 21 décembre 2017 à 14:42.
Mis à part les perfos, je vois pas trop… ce qui va être dur à justifier pour un affichage de hall…
Si t'as besoin du Gigabit pour faire du streaming 4K, et encore, pas trop optimisé (j'ai qques démos 4K qui dépassent le 100Mb/s, mais en général, même les démos qui sont là pour faire joli sont de l'ordre de 30-40Mb/s)
Le "out of box", la qualité du SAV ?
Si pour 300€ ça juste marche dans ton hall que tu te sens pas trop à installer RPi sur une carte SD, trouver comment faire booter directement sous l'affichage qui va bien… pourquoi pas ?
Mais le public visé n'est dans tous les cas pas trop le geek de LinuxFR, je ne pense pas.
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.
Et encore tu connais pas Pearl6. Il paraît qu'il est tellement lent que quand tu tapes 0.1 il a le temps de se le représenter exactement en mémoire. Ils auraient lu le Seigneur des Corps (ou des Anneaux je sais plus), ils auraient pas fait cette connerie monumentale.
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é à -6.
Donc si je résume :
De la tartine de posts je déduis donc qu'on peut rajouter :
Merci à tous d'avoir participé.
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.
Sûrement. Dis-moi c'est dans les anneaux ou les corps que tu justifies ce comportement actuel ?
Je ne comprends toujours pas comment tu peux argumenter l'utilisation de IEE-754 vs Decimal avec des théories mathématiques. Le float a pour lui énormément d'avantages, mais dès lors qu'on parle Mathématiques, il est quand même un peu un gros barbare.
Par exemple, Decimal te sors un signal dès lors qu'il sort de l'exactitude (class decimal.Inexact). Avec le type Decimal, tu sais que en calculant 1/10 tu as une valeur exacte, mais en calculant 1/3 tu n'auras qu'une approximation (10-28 par défaut au passage, le float se fait bien exploser). Perso je trouve ça un poil plus rigoureux.
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.
Ce serait donc l'aveu que ça fait tache si ce patch était mergé un jour ? (attention, je te tends un piège).
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.
Ok.
Je suppose que c'est pareil pour la représentation que propose le Decimal (je parlais du module Python que j'aime bcp, pas des décimaux dans le sens Mathématique D ).
Donc utiliser un type Decimal à la place d'un float n'apporte aucune regression sur ce plan-là.
Merci !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.