snowball a écrit 168 commentaires

Tu sais quoi ? C'est magique !
Ton python3.5 il gère un numérateur, un dénominateur, un calcul de pgcd, une division par ce pgcd pour le coût d'une seule multiplication de deux floats parce qu'en fait ta version de python, elle a transformé ta machine en ordinateur quantique… c'est de la maaaagiiiiiiiiie !!!

Tu me prends pour quoi là au juste ?
Tu es pathétique.
J'espère juste qu'une bonne dizaine de personnes te mettent ton nez dans ta crotte, mais je ne suis même pas persuadé que ça suffirait à régler ton problème psychologique.
Fin de partie pour moi.

J'ai utilisé les deux à ta demande. J'ai copié collé mes benchs. On est trois à l'avoir fait, on a tous les mêmes ratios. Tu te fiches royalement du monde…

00:13:36 ~/Téléchargements: python
Python 3.6.3 (default, Oct 24 2017, 14:48:20) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 
00:13:41 ~/Téléchargements: python2
Python 2.7.14 (default, Sep 20 2017, 01:25:59) 
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.

L'utilisation de l'un ou de l'autre n'a quasiment aucune incidence cf ces tests:

https://i.imgur.com/lbQZo1K.png

un ration de 50 que ce soit pour python3.6 ou python2.7
Ce ne sont pas mes tests, mais ce sont les prévisions que j'ai données hier. Tu ne peux pas avoir l'honnêteté de reconnaître la réalité ?
J'ai même pas envie de te dire ce que je pense de ton comportement sur ce forum.

Tes résultats confirment exactement un ratio de 50 sauf python3.5. Ton Python3.5 n'a visiblement pas utilisé le module decimal ou bien celui-ci a utilisé des floats.

Merci pour les tests en tout cas.

00:01:07 ~/Téléchargements: time python2 bench.py 

real    0m0,071s
user    0m0,083s
sys 0m0,000s
00:01:11 ~/Téléchargements: time python2 bench_dec.py 

real    0m3,525s
user    0m3,923s
sys 0m0,005s

00:01:24 ~/Téléchargements: python
Python 3.6.3 (default, Oct 24 2017, 14:48:20) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 3.5/0.07
49.99999999999999

C'est pas assez clair là ?
Arrête tes conneries, franchement tu deviens ridicule. C'est limite pathologique.

Tu peux tester perl5 vs perl6 tu verras un ratio de même ordre de grandeur.
Tu peux tester perl6 : num/Rat tu verras un ratio de même ordre de grandeur.

C'est pas un hasard punaise ! C'est juste des maths ! Et c'est normal parce qu'on fait des maths là ! C'est prévisible, calculable, démontrable…c'est juste du raisonnement.
Je t'ai expliqué dans le détail la prévision hier (tu sais, le truc que tu n'as pas voulu lire….)

Merci beaucoup de ta confirmation.

Ah bah tiens, c'est pas la peine, quelqu'un d'autre a déjà confirmé que tu es un gros coquinou et trouve exactement le même ordre de grandeur que moi :) Etrange non ??

https://i.imgur.com/veuEkqb.png

Fais gaffe, ça devient pathétique ta mauvaise foi.

Tu as une machine étonnante dis donc !!!

Chez moi:

23:31:14 ~/Téléchargements: time python bench_dec.py 

real    0m3,668s
user    0m4,009s
sys 0m0,011s
23:31:23 ~/Téléchargements: nano bench.py
23:32:04 ~/Téléchargements: time python bench.py 

real    0m0,058s
user    0m0,067s
sys 0m0,000s
23:32:07 ~/Téléchargements: python
Python 3.6.3 (default, Oct 24 2017, 14:48:20) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 3.6/0.06
60.00000000000001
>>>

On retrouve donc un facteur 60 sur ce test, ce que j'avais anticipé hier.

Tu n'aurais pas appliqué ton bench deux fois sur le même fichier :) :) Quel coquinou tu fais !!

Ca devient ridicule non ? Si quelqu'un de non étourdi (ou simplement honnête) veut bien faire le test pour confirmer, parce que là, franchement, les mots me manquent…

En fait, la raison est simple (et a été répétée au moins 10 fois): ses concepts en math sont beaucoup trop légers ce qui le handicape énormément pour comprendre ce qui lui a été dit et pour proposer des choses intéressantes sur un sujet qui concerne………des maths ! Bon cela dit, ça a (pardon, il a) progressé, c'est indéniable :)

Sinon, kantien, ton texte, c'est exactement ça. Rien à ajouter.

Preuve en image des benchs que j'ai donnés cet après midi

https://i.imgur.com/wUyMfO7.png

Divise 10.5 par 2.21, tu trouves un facteur de combien ?

Hier tu m'as écrit ça

https://i.imgur.com/wUyMfO7.png (t'es gonflé quand même, vu comment ils ont totalement abandonné l'idée)

Je t'ai répondu ça

https://i.imgur.com/y0JB1wt.png

Puis tu m'as totalement méprisé avec cette réponse (intelligente tu crois ?)

https://i.imgur.com/axZ1kIk.png

Tu n'aurais pas raté des dizaines d'occasion de te taire ?

Sans parler du moment où tu penses que je serai ridiculisé bientôt devant mes étudiants en me disant, qu'heureusement, je suis sous un pseudo alors même que j'ai donné un lien avec mon cours et mon vrai nom….Bref…t'as franchement pas fait fort…

T'as confirmé le facteur 50 avec Python3 ?

oui (decimal vs float)

T'as trouvé ton facteur 50 en Perl ?

oui (num vs Rat)

Fais les bench toi même et tu constateras ces ordres de grandeur (qui peuvent varier d'une mesure à l'autre et qu'il faut donc répéter pas mal de fois pour avoir une tendance moyenne)

Mais c'est totalement prévisible vu qu'il n'y a rien de magique: c'est juste des maths quoi. Il me semble avoir expliqué dans le détail hier pourquoi on aurait ces ordres de grandeur. Je n'ai pas lancé ça au hasard, vu que ce genre de choses je passe environ 4 mois par an à le tester, à l'expliquer, à le ré expliquer encore et encore, car ça fait partie de mon métier (depuis maintenant 4 ans). Je ne me considère pas comme un expert, mais on va dire que j'ai suffisamment de math en poche et d'expérience pour comprendre le process dans le détail (avec les étudiants, on fouine même l'assembleur produit par les différentes options de compil de gcc pour comprendre les subtilités, les magic numbers pour transformer des divisions en simples multiplications etc).

Dialogue de sourds :)

De mon côté, je t'écoute, je prends le temps d'argumenter et j'étaye par des maths (que tu ne lis pas) ou par des bench (ça, heureusement, tu prends, j'ai de la chance).

Il me semble pourtant qu' en faisant des maths hier, je t'avais calculé le facteur 50 de chute des perfs non ? Mais visiblement tu ne voulais pas lire, tout persuadé que si des gars l'avaient poussé dans perl6 c'est que tu avais raison. C'est donc bien ta surdité qui est en cause, pas la mienne. Vu l'énergie que j'ai dû dépenser à argumenter je mérite au moins que tu ne me taxes pas de surdité il me semble.

Dis moi, t'es fâché avec les maths en vrai, c'est ça non ?

Cette idée n'a pas été retenue pour les raisons invoquées par Guido lui même dans le lien que tu as donné. Il a donné les principales absurdités que ça entraînait, d'autres t'ont été données par plusieurs autres intervenants ici à plusieurs reprises.

En fait, la science a fait le tour de ces sujets depuis très longtemps (avant même que (que la technologie informatique n'existe je pense), tout comme Blaise Pascal avait déjà tous les algos et leur complexité avant même la naissance de la première calculatrice: c'est la magie des maths.

Grâce aux maths, nn sait exactement ce qu'on ne peut pas obtenir, on sait à l'avance combien coûte ce qu'on aurait pu désirer, on sait décider pour quels problèmes il faut choisir de la virgule fixe, on sait aussi quelle limite ça a, on l'a déjà implémenté dans les langages standard, on l'a implémenté de manière optimale etc etc. De ce côté là, on n'a plus rien à chercher et on l'a démontré.

En analyse numérique on est allé bien plus loin que ces considérations depuis des années. C'est pour ça que ce que tu as raconté pendant des pages était aussi agaçant (la suffisance (involontaire ?) vis à vis de la communauté scientifique et l'ignorance ça fait un mauvais mélange, surtout le passage où on était limite dans la phase 'génie incompris').

Peace et noyeux joel.

https://i.imgur.com/cYk1ub5.png
et ma version
https://i.imgur.com/UjEuZOr.png

Ne parle pas trop vite, il y retourne là :)

Non tu n'as pas fait le même test.
Tu t'arrêtes (volontairement) au 46 ème terme. Coquinou :)

Mais dès que tu ajoutes un tout petit rationnel 1/47 (c'est pas demandé la lune d'ajouter 1/47), PAF, CRASH total de perl …au revoir…
Voilà les dangers: aucun contrôle possible, aucune dynamique possible (ajouter un 47ème c'est une demande de dynamique ridicule).

Me dis pas que tu n'as toujours pas compris hein !

Et si tu lis cette conversation, tu verras que l'implementation Decimal (cdecimal) devient plus raisonnable pour un passage à default.

Tu peux résumer ce que tu en as compris ? Parce qu'il est intéressant ton lien… Guido n'est pas tendre du tout avec l'idée de passer au Decimal par défaut. C'est limpide, clair: l'absurdité a été rejetée par l'équipe en moins de deux jours !

https://mail.python.org/pipermail/python-ideas/2012-September/016252.html

C'est marrant on dirait mot pour mot ce qu'on t'a répété pendant plus de 100 posts :)

Et la conclusion du thread, ….

https://mail.python.org/pipermail/python-ideas/2012-September/016256.html

time python bench.py % bench avec le module decimal sur python3

real    0m3,499s
user    0m4,000s
sys 0m0,006s

time python bench.py % bench avec des floats sur python3

real    0m0,069s
user    0m0,075s
sys 0m0,000s

J'obtiens quasiment exactement la même chose avec python2

C'est à dire que le module decimal divise les perfs par 50. C'était totalement prévisible cette baisse énorme de perf non ? Qu'est-ce que tu as trouvé amusant ?

Je pense qu'en fait ça vient du fait que pour additionner deux fractions a/b+c/d il fait Num=ad+bc et Den=cd. Ensuite il fait un calcul de PGCD pour diviser Num et Den par ce pgcd.
Mais pour les décimaux il faut rajouter une étape qui consiste à chercher un multiple de Den qui est une puissance de 10. Et ça, ça coûte cher, très cher. Visiblement ça coûte autant que l'étape précédente.
Mais bon de toute façon ça n'a aucun intérêt (sauf dans la proportion de un cas sur des milliards).

Oui il y a une typo ! C'est S+=1/i (et non S+=S+1/i )

De rien :)

Oups, oui tu as tout à fait raison. Gros gros bug de ma part :) J'ai honte :)

Par contre, j'ai fait le test avec perl6 et il se vautre (arrêt brutal du programme) simplement en demandant les 47 premiers termes de la suite.

Les joyeusetés de perl6 et la quête (absurde) de l'exactitude

On veut calculer la somme des inverses des 1/i pour i de 1 à 47… Ce qui nécessite un minimum de dynamique…

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

bin, ça se vautre… prévisible….

La même avec des floats

S=0
for i in range (2,48):
  S += S + 1/i
print (S)

Ca fait exactement ce qu'on attend avec une précision à près… Comme quoi, y a pas qu'une question de perfs qui justifie l'utilisation des floats…

Bien vu !
Du coup je viens de faire le test en forçant l'utilisation du float à la place du Rat par défaut et paf ! on revient aux perfs de perl5. Donc c'est bien le Rat qui est en cause. CQFD.

PS
(oui je me réponds à moi-même et je sais que ça se fait pas :) )

Imaginez un peu l'envolée du bench en perl6 si j'avais fait la somme des 1/(1+$i) dans la boucle :) Sachant que s'il essaye de rester exact, il aurait eu un dénominateur de l'ordre de factoriel 1000 ! (quelques centaines de mégaoctets en mémoire quoi)