gUI a écrit 5994 commentaires

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.

Un décimal est un réel.

Oui, mais moi je parle des décimaux. Et les réels ne sont pas tous des décimaux. Alors limitons-nous aux décimaux svp.

tu souhaites représenter EXACTEMENT 1.8 en machine donc que tu veux une précision infinie.

Non. Pas d'accord avec ton "donc".

char[3]={'1','.','8'} est une représentation de 1.8 sur simplement 3 octets. C'est donc possible. Attention ne pas me reprocher ton manque d'imagination.

Encore une fois, la bibliothèque Decimal de Python fait exactement ce que je demande, donc pas la peine de m'expliquer que c'est pas possible.

Donc j'ai du mal avec la suite de ton propos qui tente encore une fois de m'expliquer que pour 1/3 c'est compliqué. Il est bien, mais hors sujet.

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

qu'une autre façon de penser que la tienne

Je ne suis pas seul à penser que 2.0 - 1.8 - 0.2 = 0.0 dans tous les cas. Mais tu ne m'as pas donné un autre exemple que celui d'un ordinateur qui utilise IEE-754. C'est un peu juste comme généralité.

tu soutiens sans aucune démonstration que les utilisateurs Python veulent ta façon de penser

Oui, je soutiens sans honte que les gens veulent effectuer des calculs comme on leur a toujours expliqué, et pas des façons de penser alternatives où 2.0 - 1.8 - 0.2 = presque 0.0

La performance leur fait accepter des erreurs minimes, mais si à perfo égale on avait la précision, ils prendraient sans hésiter, au lieu de préférer l'approximation qui est fausse.

Je veux bien un exemple (autre que qqu'un de pressé) qui préfère avoir 2.0 - 1.8 - 0.2 != 0.0

Je ne veux pas qqu'un que ça ne dérange pas (trop facile, c'est l'immense majorité des gens, je n'ai jamais dit le contraire), je veux qqu'un qui préfère. Je pense que ça n'existe pas. Je dis donc que les gens que ça ne gêne pas acceptent cette erreur pour la seule raison de performance, et pas parce qu'ils ont une façon de penser différente de moi.

Moi j'en connais plein qui préfèrent avoir 2.0 - 1.8 - 0.2 == 0.0, ce sont tous ceux qui utilisent les bibliothèques dédiées.

Un simple contre exemple éclairera ma lanterne.

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

J'allais te dire la même chose : tu lis ou pas mes réponses ?

Je ne parle pas de réels, mais de décimaux. Je ne parle pas de précision infinie, mais bien de 1.8 et 0.2

Tu me dis que la science DEMONTRE qu'on ne peut pas faire mieux, et pourtant les 3/4 des commentaires me disent qu'il me suffit d'utiliser des bibliothèques dédiées.

Par exemple Python propose Decimal qui est très bien, à ceci près qu'il faut le taper à chaque fois, alors que c'est 99% du temps ce que les gens veulent en fait (c'est ce que je soutiens). C'est con, je ne trouve pas cette situation si inévitable comme tout le monde tente de me l'expliquer.

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

Rassure-moi : tu trolles pour le plaisir, tu te dévoileras un jour?

Non, là tu m'as définitivement perdu. Zéro sur une soustraction de 3 nombre décimaux… non, je ne comprends pas.

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

Ah non, on n'a pas fat les même Math, je confirme. Celles qu'on m'a enseignées ne m'ont pas parlé de précision sur un nombre décimal comme 0.2 ou 1.8
Ce sont des valeurs, c'est tout.

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

Le problème est que dans ta tête c'est vrai dans tous les cas.

Je reformule, dis-moi si j'ai bon.

Pour les humains, il n'existe qu'une seule façon de compter : les mathématiques. Celles qui ne souffrent pas d'approximation, et où 2.0 - 1.8 - 0.2 = 0.0 exactement.

Là on se "contente" d'utiliser un ordi, qui fait ce qu'il veut le pauvre, et 0.1 est déjà un enfer pour lui, alors imaginez une soustraction.

Et tant que tu ne comprendras pas qu'il n'existe pas une "meilleure façon de compter"

J'ai la faiblesse de penser que la meilleure existe, c'est la version des humains. J'ai aussi la faiblesse de penser que les ordinateurs sont en priorité au service des humains, et que pour des calculs simples et humainement atteignables, il serait bon qu'ils fassent aussi bien.

Pour les calculs de Pi et de racine(2), pas de pb, je me contente parfaitement de ce qu'ils m'apportent, c'est à dire une précision que ma faible intelligence ne peut même pas évalue.

Le journal est marqué humour.

Bien sûr, j'essaie juste de rentrer dans la logique (et tu noteras que je ne me suis jamais emporté, même si j'en ai pris plein la gueule). Si le journal se contentait de dire "printf("OK") => OK" ce ne serait pas de l'humour, pourtant il a aussi comme résultat ce qu'il a demandé. Si il y a de l'humour dedans, c'est bien que ce résultat est quelque peu incongru vis-à-vis de nos attentes. Enfin, je le crois.

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

Tu sors un poil du sujet, je ne parle que des décimaux, pas besoin de précision infinie ni de calcul formel.

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

et tu voudrais que le reste du monde change ses outils

Si dans le prochain Python v4, v5 ou v12 on peut écrire "2-0 - 1.8 - 0.2 == 0.0 => True", tu penseras que ça va casser de la compatiblité ? Voire que ce sera une régression ?

Je te souhaite que ça n'arrive jamais, parce que sinon, il va m'en falloir des +1 pour compenser tout ce que j'ai mangé hier et aujourd'hui :)

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

mais pourquoi les utiliser par défaut ?

Quelle idée saugrenue, tu as raison. Un bon programmeur n'a besoin que du binaire. Laissons le reste à Excel !

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

Ah merde t'as raison, j'avais lu trop vite :)

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

Un logiciel de calcul formel qui fait du calcul avec des réels ne fait d'ailleurs que ce que IEEE754 fait

J'avoue être un peu déçu. Parce que si c'est ça, il continuera à me dire que (2.0 - 1.8 - 0.2) == 0.0 est FALSE puisque au lieu d'avoir une erreur d'arrondi au 64e bit, il l'aura au milliardième bit (par exemple).

Du coup il ne résoud pas mon pb : je voudrais juste qu'il me dise "TRUE". C'est pas demander la Lune quand même, si ?

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

Ah si, bc fait mieux, c'est un fait.

Pour bc, (2.0 - 1.8 - 0.2) == 0.0 => 1 (c'est à dire TRUE)
Les autres langages (j'ai vérifié en C et en Python) répondent que c'est FALSE.

Je vais bencher bc vs Python pour voir si c'est si cher que ça tiens.

Je pense que si ça tourne au troll, c'est que tout le monde m'explique que c'est comme ça, alors que j'explique que ça pourrait être mieux.

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

juste pour de la précision qui n'apporte rien ?

Encore une fois, le réalisme l'emporte sur la beauté, sur l'idéalisme.

Tant pis, on se contentera de la situation actuelle : les langages les plus utilisés aujourd'hui répondent que "(2.0 - 1.8 - 0.2) != 0.0".

Je m'en vais repartir à mes occupations ordinaires, le cœur gros.

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

Tout ça pour dire qu'en corrigeant ton problème avec des virgules fixe

Je trouve que ça manque d'imagination. Qui a parlé de virgules fixes ? On pourrait pas réfléchir à un truc un poil plus malin ?

Par exemple, on m'a expliqué 500x que bc fait ça très bien (j'ai vérifié, c'est vrai). Pourquoi les langages simples n'utilisent pas l'implémentation de bc par défaut, quitte à activer l'IEEE quand on a besoin de perfos ?

Autrement dit, par défaut, les neuneus se cognent une implémentation limitée mais ultra performante, par contre, ceux qui connaissent bien, eux, ils ont accès à des bibliothèques de bien meilleure précision, quitte à perdre en perfos.

Les neuneus ont-ils besoin de perfo ou d'exactitude ?

je pense que vu les perfos actuelles des CPUs, on peut changer, oui…

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

En matière de soustraction… je le pense. En tous cas il est temps qu'on en parle :)

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

Ouais pas mal comme approche ça. Implémenter les intervalles lorsqu'on manipule des valeurs flottantes.

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

Si tu demandes une test de comparaisons à 0.1 près, c'est (2.0 - 1.8 - 0.2) > -0.1 ou <0.1 (je schématise) que tu aurais dû demander.

OH MON DIEU !

Tiré de la doc de Python :

Also, since the 0.1 cannot get any closer to the exact value of 1/10 and 0.3 cannot get any closer to the exact value of 3/10, then pre-rounding with round() function cannot help:

round(.1, 1) + round(.1, 1) + round(.1, 1) == round(.3, 1)
=> False

Même ça c'est faux. C'est pas tout à fait ce que tu as dit (restons stricts), mais là quand même… j'avoue que je me serais bien fait avoir.

Honnêtement, tu l'aurais anticipé ?

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

Regarde les notes moyennes de mes commentaires (pas sur ce thread bien sûr), je ne suis pas inquiet pour mon Karma, il s'en remettra :)

Non je trouve curieux quand même de me faire débourrer la gueule juste parce que je dis que ce résultat est quand même curieux quand on y pense. C'est tout. Personne pour dire "oui, c'est un peu con, mais bon, un ordi ça reste un ordi, ça se saurait si ils étaient intelligents". Personne pour dire un truc comme "c'est vrai qu'à l'heure de l'intelligence artificielle, ça fait tâche".

Je suis étonné de la réaction du site (que j'ai la prétention de connaître pas mal). Je joue au troll en insistant, mais mon idée de base, désolé, vous m'avez pas convaincu :(

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

Voilà, ou déjà un warning. Au moins on pourrait me répondre "mais tu fais de la merde, t'as un warning à la compilation".

Merci :)

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

Si tu demandes une test de comparaisons à 0.1 près, c'est (2.0 - 1.8 - 0.2) > -0.1 ou <0.1 (je schématise)

Non mais j'ai pas de soucis avec ça, c'est correct ton truc, c'est comme ça qu'on me l'a appris d'ailleurs, jamais de "==" avec des floats (exactement pour cette raison). Pourtant :
- la syntaxe est correcte
- le résultat est faux
- on l'accepte

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

Tu te trompes, le résultat renvoyé par Python est précis à 10-16 près (ce qui est pas mal), on est loin d'une imprécision de 10-1 que tu sembles sous entendre.

Je ne la sous-entend pas, je l'affirme.

(2.0 - 1.8 - 0.2) == 0.0
=> False

Je suis pas allé très loin en précision, tu en conviens ?

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