gUI a écrit 6231 commentaires

Mais c'est magnifique de bêtise et de préjugé ça

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.

Peut-être est-ce aussi ton cas ?

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.

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.

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.

4(0.5) - 2(0.9 +/- ε) - (0.2 +/- ε)

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.

Donc si je résume :

• de toutes façons on n'arrivera jamais à une représentation parfaite (c'est snowball qui va être content)
• à faire faux, autant faire vite (quitte à ce que ce soit encore plus faux)
• et tant pis pour les soustractions à 1 chiffre après la virgule, du moment qu'on peut calculer une fonction de Bessel ou une fonction gamma d'Euler rapidement
• 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.0
False

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.

Si ça fait "tâche" (selon toi), tu n'as qu'à faire une fonction qui formate l'affichage pour arrondir les résultats aux décimaux les plus proches.

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.

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.

notion de structure algébrique (groupe, anneau et corps).

Vu que tu as appris ça et pas moi, tu pourrais rapidement me dire :
- si l'IEEE-754 est un groupe, un anneau, un corps ?
- pareil pour Decimal ?

Ensuite je potasserai sur le sujet avec grand plaisir en cherchant ce qu'on perd comme propriétés en passant de float à Decimal.

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

une personne affirme que c'est un bug alors que c'est un choix

Très honnêtement, je regrette mon "bug". Tu as raison, c'est dans la spec Python, ce n'en est donc pas un. Je voudrais revenir à mes premiers propos : ça fait tache (c'est mon opinion, ce n'est pas factuel). Je ne renie en rien l'immense majorité de mes messages où je dis juste qu'on peut vraiment pas mieux faire ? (oui, le "mieux" est tout aussi subjectif, chacun son "mieux").

Il faut toutefois remarquer que je ne suis pas le seul à trouver que ça fait tache, puisque pour arriver à ça :

Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1.1
1.1

il a fallu quand même patcher Python et ça : https://bugs.python.org/issue1580

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

Avec acceptation que la perf est moins important que la précision (cette phrase est importante, et change tout).

Oh oui.

Mon discours depuis le début c'est "le seul avantage des floats, c'est la perfo. Aujourd'hui on a des CPUs plus puissants qu'il y a 30 ans - date de l'IEEE-754 - peut-être pourrait-on envisager d'éventuellement commencer à penser que peut-être il se pourrait qu'il soit temps de se demander à passer à autre chose, et donc gagner en exactitude et/ou précision, au moins dans les langages courants et généralistes, ceux qui ne sont pas à priori taillé pour la performance ?"

Avec ça vient rapidement la deuxième question que tu poses aussi : où est le "classique" et où est le "particulier" ? Dans la précision ou dans la performance ? Sujet autrement plus intéressant que de savoir si ça va résoudre le pb de la représentation de 1/3 en décimal, mais qui - je le déplore, crois-moi - a occupé une bonne moitié des posts de ce troll.

Comment évaluer les besoins "de l'humanité" ? Un audit du code Python présent sur Github ? Une recherche "Python for performance" et "Python for accuracy" sur Google ?

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

Que Decimal ne soit pas très fort à représenter des non-decimaux, c'est pas trop nouveau comme idée. Mais c'est bien de me ressortir le même argument pour la 10e fois, ça me permet de m'entraîner à répondre.

Float :
- 1/3 n'est pas représentable. Erreur de l'ordre de 10^-17 (Evalué par un "1.0 - 2/3" en Python v3)
- 0.1 n'est pas représentable : Erreur de l'ordre de 10^-17

Decimal :
- 1/3 n'est pas représentable. Erreur de l'ordre de 10^-28 par défaut, mais on peut baisser sur simple demande pour ne pas choquer ceux qui préfèrent la précision des float (et sûrement pour économiser du CPU, ne nous cachons pas)
- 0.1 est représentable. Pas d'erreur.

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

Après vérification, c'est exactement ce pour quoi comm est fait. Il te sort directement ce qui est commun, ce qui n'est que dans le premier fichier et ce qui n'est que dans la 2nd. A la fois diff et grep en quelques sortes.

Par contre il a un pré-requis peut-être rédhibitoire : les lignes doivent être triées.

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

Et puis l'intégration avec l'OS qui doit être aux petits oignons et donc une bonne perf.

Je me méfie comme de la peste de cet argument. Un kernel Linux de base a déjà une excellente utilisation du matériel, surtout de la famille PC x86, encore plus avec Intel (notamment la partie graphique).

Les petits oignons ça peut être quoi ? Quelques réglages dûs au fait que le support est de la flash et pas un disque mécanique ? Un choix des applis par défaut adapté au processeur et à la quantité de RAM ? Au final, ça sent le Ubuntu classique, pas de quoi révolutionner les performances non plus…

En tous cas, si c'est vraiment le cas, il faudrait le mettre bcp plus en avant.

Je pense que la plus-value du produit est dans le logiciel "LinuTop Kiosk" pré-installé, dans le fait qu'un NUC avec un processeur aussi faible (donc basse conso) n'existe pas. Bref sûrement un très bon produit si il est utilisé pour ce à quoi il a été conçu : un kiosque d'affichage dans un hall d'entrée.

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

Clair, c'est compliqué de bouger un truc aussi "de base" que la représentation des nombres. C'est hyper casse-geule, et ce thread troll m'aura au moins appris le changement fondamental (et ô combien risqué !) qu'a apporté le int * int -> float

Pour les litéraux, l'idée serait en effet de partir sur des Decimaux, sauf si :
- on précise qu'on veut un float (bien évidemment)
- le littéral a trop de chiffres significatifs, ou une précision trop grande (bref, il est pas représentable en Décimal)

Ensuite tu manipules : tu additionnes (bcp de chances que tu restes en Decimaux), soustraits (idem), multiplie (attention, ça va plus facilement déborder) ou divise (là on le sait, c'est souvent la complication). Tant que tout va bien, tu restes en Decimal. Comme le Decimal propose déjà tout un tas de signaux, notamment pour les débordements et pour la perte d'exactitude, on peut imaginer de se raccrocher à ça en se disant "ok, j'abandonne, passons en flottant" (avant la dite opération, ce qui sous-entend que tu fais l'opération, tu vois que ça pête, donc tu convertis tes 2 opérandes en float, puis tu refais l'opération en float… )

Le pb c'est que le programmeur à priori ne sais pas si il aura affaire à un Décimal ou à un flottant, et là ça fait pas trop plaisir en général. Il peut toujours récupérer le signal de perte d'exactitude, il saura qu'on a basculé (ou tester le type() )…

Mais du coup, tu gardes une exactitude sur les valeurs courantes "du CM2", mais tu gardes la puissance de représentation de l'IEEE quand ça se fait sentir.

Et reste le pb des perfos bien évidemment.

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

Cela dit, l'histoire de l'arrivée du "int * int -> float" est très intéressante : http://python-history.blogspot.fr/2009/03/problem-with-integer-division.html

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

Je suis déçuuuuuuuuuuuu !

>>> type(2)
<class 'int'>
>>> type(1)
<class 'int'>
>>> type(2/1)
<class 'float'>

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

Alors j'ai pas plus testé que ça, mais je crois bien que comm fait ça.

• Tu prends ton fichier original
• Tu grep pour avoir ton fichier qui contient
• Avec comm (compare) tu auras la possibilité de sortir les lignes du fichier1 qui ne sont pas dans le fichier2

C'est sympa de voir le nb de solutions différentes au même pb :)

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

(ce qui ne change pas les problèmes d'arrondis et l'impossibilité d'avoir une représentation finie en base 2 pour certaines fractions)

Je sais, mais ce n'est pas de ça dont je parle.

Si tu veux calculer formellement sur des fractions en python

Non, je ne veux pas. Ce n'est pas de ça dont je parle non plus. Et le journal non plus.

Je parle simplement du cas qu'on connait déjà, qui est par exemple déjà implémenté dans https://docs.python.org/3/library/decimal.html

Merci de lire le 3e point de la page de la doc de Python. C'est exactement de ça dont je parle, c'est exactement la solution au problème exposé dans ce journal.

Aujourd'hui, c'est une option, comme jadis l'était l'IEEE. Maintenant que Python switche tout seul de l'int à l'IEEE quand il le juge bon, va-t-il un jour switcher de int à Decimal à IEEE quand il le juge bon ?

Decimal a ses limitations, certes, mais c'est en échange d'avantages (lire la doc de Python, c'est le premier chapitre, c'est très clairement expliqué). En maintenant la représentation Decimal le plus longtemps possible, on garde l'exactitude dans les "petits Mathématiques de CM2". Dès que c'est compliqué, dès que ça sort, on passe en IEEE, comme d'hab.

Est-ce qu'on se sert majoritairement de Python pour faire des maths à qques chiffres après la virgule dans des ordres de grandeur relativement petits, ou est-ce qu'on se sert de Python pour manipuler des grands nombre (en perdant de la précision) ou des petits nombres (avec une grande précision) ? Là est la question.

C'est tout :)

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

Tu veux quoi, que l’interpréteur tente de « simplifier » l’expression avant de la calculer ?

Pas tout à fait. Tant qu'il peut éviter IEEE-754, qu'il le fasse : qu'il garde le int tant qu'il peut, qu'il garde le decimal tant qu'il peut, qu'il finisse IEEE quand il n'y a plus le choix (1/3 par exemple).

T’as le moindre début de commencement d’idée de patch sur python ?

Je pourrais par exemple chercher le passage où actuellement il garde le int le plus longtemps possible avant de passer au float.

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

Ada ne fera qu'une partie de ce que tu veux.

Incroyable.

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