gUI a écrit 5994 commentaires

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.

Je l'ai déjà autre part sur un autre fil mais ce que tu veux n'a pas d'intérêt

C'est sûrement pour ça qu'il existe des dizaines de bibliothèques qui font déjà ça.

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

Tu ne comprends toujours pas ce que tu veux est impossible ?

Non, ce que tu penses que je veux est impossible. Mais ce que je veux est possible puisque ça existe déjà (tu me l'as dit toi-même : Ada le fait)

M'expliquer pour la 100e fois que la précision infinie n'est pas possible ne sert à rien parce que je le sais déjà, et ça tombe bien, je n'ai jamais demandé ça.

L'implémentation dont tu parles par exemple est finie (limitée à une précision de 10^-99), et correspond parfaitement à mon besoin, puisque avec cette implémentation, on aura bien "2.0 - 1.8 - 0.2 = 0.0".

Tu vois que ce que je veux est possible ?

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

son type 'automagiquement' en décimal, et le fasse à chaque opérations (exit le pipeline), et tant pis pour les perf.

Au moins t'as compris ce dont je parle, c'est exactement ça, je te remercie d'avoir fait l'effort.

Je me dis aussi que vu que Python le fait déjà dans un autre cas (il passe automagiquement de entier à float selon le contexte - voir un thread un peu plus bas) c'est pas si saugrenu que ça, et il y a bien un jour (peut-être pas si loin ? Python v4 ? v5 ?) où "tant pis pour les perfs" sera acceptable en échange d'un certain confort, d'une certaine facilité de programmation… et du gain en exactitude sur les mathématiques de CM2.

Encore merci.

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

En math, tu parles math, pas représentation des flottants. En tous cas c'était encore le cas quand j'étais en dernière année de CM2.

Mon prof de math ne me mettais pas zéro parce que j'avais oublié de préciser ±sys.float_info.epslion. Il considérait simplement que 2.0 - 1.8 - 0.2 = 0.0

Je pense que mon pb vient de là : non seulement j'ai pas dépassé le CM2, mais en plus on m'a raconté des conneries.

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

Ok j'ai compris, merci :)

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

Meeeeeeerde ! Il s'est réveillé !!!

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

J'ai pas compris ton point A. Même si j'ai pas dépassé le CM2, je sais que 1/2 tombe juste même en IEEE-754 et donc 0,5 exactement. Donc de quel cassage de compatibilité tu parles ?

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

Je ne serais pas surpris qu’ils aient utilisé systématiquement des flottants en BCD (et pas d’entiers)

En tous cas c'est une représentation naïve mais qui doit être facile à implémenter, et surtout qui correspond très bien à la vision humaine des mathématiques. Quand on nous apprend à compter, on nous fait faire du BCD (une case pour les unités, une case pour dizaines etc.).

Il semblerait même qu'on ait hérité de cette époque une vieille compatibilité hardware avec le BCD (uniquement en entier apparemment) : https://en.wikipedia.org/wiki/Intel_BCD_opcode

Merci pour la précision.

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

C’est bien parce que ça marche mieux comme ça

Oui, j'aurais dû y penser avant, tu as raison. C'est un très bon argument.

Sot que je suis.

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

Donc reconnais que ta remarque est idiote

D'accord. Il est idiot d'espérer d'avoir un jour (2.0 - 1.8 - 0.2) = 0.0 dans un langage de programmation courant.

Pour cela il faudrait un ordinateur inifi il paraît. Ou utiliser une bibliothèque spécialisée, j'ai eu les 2 réponses, je ne sais pas laquelle est bonne, mais en tous les cas c'est hyper compliqué, je peux pas comprendre avec mes Math de CM2 qui m'ont juste expliqué que ça vaut zéro, dans tous les cas.

L'IEEE-754 est la seule représentation raisonnable, tout le reste est une hérésie technique. Je le saurais si j'avais fait des études après le CM2.

Putain, j'ai bien failli passer au bucher moi pour oser imaginer autre chose.

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

Mais il y a fort à parier que l'espace et le temps soient discrets, et donc que les nombres réels n'existent pas.

C'est bon ça ! J'adore le concept. Et puis ça rabat le caquet à certaines certitudes.

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

Avec ça tu ne peux même pas programmer la moindre résolution de problème de niveau supérieur au CE2.

Oui mais au moins ce sera juste avec des pb de CE2, contrairement à la situation actuelle ou c'est faux pour les pb de CE2 et les pb supérieurs.

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