gUI a écrit 6011 commentaires

100% d'accord.

Quand il y a eu le pb des "frondeurs" et que Valls est passé par le 49.3, je disais que le déni de démocracie, c'était pas Valls, c'était les "frondeurs" qui étaient incapables de voter la motion de censure qui allait avec le 49.3

Je disais ça aussi tranquillement vu que j'étais politiquement plus proche des frondeurs que de Valls.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

100% d'accord.

Quand il y a eu le pb des "frondeurs" et que Valls est passé par le 49.3, je disais que le déni de démocracie, c'était pas Valls, c'était les "frondeurs" qui étaient incapables de voter la motion de censure qui était avec le 49.3

Je disais ça aussi tranquillement vu que j'étais politiquement plus proche des frondeurs que de Valls.

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Anéfé, il me manquait une boucle :)
Et là oui ça devient passionnant !

Le mien ne plante pas. Si je modifie "<48", les 2 dernières lignes :

(4597683817803138427 1345655451257488800)
No such method 'nude' for invocant of type 'Num

=> Il a quitté tout seul rationnal pour choisir un autre type.

Si je remets un bon vieux "say" qui sera compatible avec tous les types, mes 2 dernières lignes sont :
3.41668724598610475071
3.43796384173079

=> Par contre il a perdu énormément de précision au passage en float, c'était bcp mieux le rationnal (et exact !)

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Moi aussi j'ai fait le test en perl6

Le code :

#!/usr/bin/perl6

my $S=0;

loop (my $i=2; $i < 47; $i++) {
  $S += 1/$i; 
  say $S.nude;
}

Le résultat : (j'explique entre parenthèse comment lire nude qui donne la représentation interne).

(1 2) => 1/2
(5 6) => 1/2 + 1/3 = 3/6 + 2/6 = 5/6
(13 12) => 1/2 + 1/3 + 1/4 = 6/12 + 4/12 + 3/12 = 13/12
(77 60) => 1/2 + 1/3 + 1/4 + 1/5 = 30/60 + 20/60 + 15/60 + 12/60 = 77/60
(29 20)
(223 140)
(481 280)
(4609 2520)
(4861 2520)
(55991 27720)
(58301 27720)
(785633 360360)
(811373 360360)
(835397 360360)
(1715839 720720)
(29889983 12252240)
(10190221 4084080)
(197698279 77597520)
(40315631 15519504)
(13684885 5173168)
(13920029 5173168)
(325333835 118982864)
(990874363 356948592)
(25128807667 8923714800)
(25472027467 8923714800)
(232222818803 80313433200)
(235091155703 80313433200)
(6897956948587 2329089562800)
(6975593267347 2329089562800)
(218572480850557 72201776446800)
(441657572729039 144403552893600)
(40548494360749 13127595717600)
(40934600117149 13127595717600)
(41309674280509 13127595717600)
(41674329717109 13127595717600)
(1555077795250633 485721041551200)
(1567859927923033 485721041551200)
(1580314313603833 485721041551200)
(1592457339642613 485721041551200)
(65776471966898333 19914562703599200)
(9464375460249419 2844937529085600)
(409813082319810617 122332313750680800)
(4538526983955586987 1345655451257488800)
(4568430438427975627 1345655451257488800)
(4597683817803138427 1345655451257488800)

Alors très honnêtement j'ai pas la patience de vérifier, et encore plus honnêtement j'ai pas le niveau pour vérifier facilement. Tu saurais me dire si la valeur finale est exacte ou pas ?

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

Je parlais du bench Python moi. J'ai comme lui sous Python2, mais plus du tout sous Python3.

Et si tu lis cette conversation, tu verras que l'implementation Decimal (cdecimal) devient plus raisonnable pour un passage à default.
https://mail.python.org/pipermail/python-ideas/2012-September/016250.html

En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

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.

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.

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.

merde alors

Ca, tu peux le dire :)

Note bien le calcul en flottant ne fait pas mieux

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.

Je ne vois par l'intérêt

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.

à par se branler la nouille.

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.

Avoir du code qui va péter parce qu'on aura silencieusement modifié un type d'une variable…

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.

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.

Et quel est le gain de le faire ?

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.

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.

Tu confonds "ils n'ont pas le droit de" et "ils n'ont pas les couilles de".

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.

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.

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.

D'une part je ne suis pas sûr que l'électrique soit vraiment plus écolo

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.

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.

Je ne savais pas pour Perl6, l’avenir nous dira si les autres langages finissent par adopter ce comportement déviant original.

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.

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.

Tes additions, multiplications etc font toutes appel à ses fonctions internes et s'appuient sur IEEE754, désolé de te décevoir.

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.

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.