gUI a écrit 6090 commentaires

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.

Perso, je me restreins à la toute première phrase du journal :)

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

T'es sacrément gonflé quand même. Tu me dis toi-même qu'il y a des langages pour ça (en citant Ada, je te crois sur parole)… ce sont donc des langages absurdes qui ne servent à rien ?

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

Donc tu veux juste faire des additions et multiplications sur quelques décimaux pas trop grands.

Oui. On m'accuse de pas écouter les autres, mais j'ai l'impression que quand même on m'écoute pas trop.

Dans ce cas là, tu as plein de langages qui font ça très bien

Je sais, merci, on me l'a expliqué 50x alors que je le savais déjà. Mais ce sont des langages spécifiques, ou peu utilisés, ou des langages courants mais via une lib dédiée.

Mon propos depuis le début c'est pourquoi avec les progrès actuels des CPUs qui passent leur temps à se toucher la nouille en attendant qu'on clique sur un chat sur Youtube (ou qu'on tape la touche suivante pendant qu'on tape le dernier troll sur LinuxFR) on pourrait pas imaginer d'activer ça par défaut dans des langages courants, comme Python qui est l'exemple parfait, tout en laissant la possibilité à ceux qui cherchent réellement la performance de le désactiver facilement (pragma ou compil).

Ça éviterait cet écueil… c'est l'objet du journal humouristique quoi… c'est rigolo de se rappeler qu'il se trompe (c'est un fait) sur une soustraction simple.

Encore une fois, pour rappel, le début du post c'est un mec qui tape une soustraction en Python intéractif. La justification "oui mais c'est plus lent" est un peu limite et puis je ne veux de toutes façons pas jeter IEEE-754 à la poubelle.

Donc oui, la raison est la perfo, je veux bien qu'on parle de perfo, mais pas de :
- c'est pareil dans les autres langages
- ça ne résout pas la représentation de 1/3
- on a démontré scientifiquement que c'est pas possible
- c'est pas une faute de mathématiques, c'est juste TES mathématiques qui sont comme ça (celle là j'avoue je l'ai pas trop comprise, mais comme il a l'air sûr de lui…)

Mais ouvrir l'esprit, dire qu'on pourrait peut-être imaginer un système un poil plus évolué, que la technique a évolué et qu'on pourrait en profiter… c'est pas facile pour tout le monde… "prends ta calculatrice si tu veux soustraire 1.8 et 0.2 !".

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

Résultat intermédiaire qui n'est pas décimal, donc évidemment que ça se vautre… j'ai jamais demandé à résoudre ça.
Encore une fois, on sort du cadre du message original, et donc de ma remarque initiale.

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