gUI a écrit 6184 commentaires

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.

Le troll c'est le troll , c'est dur de résister :) Et puis sur LinuxFR, on a nos habitudes…

Bon, allez, je vais accepter la fatalité : (2.0 - 1.8 - 0.2) == 0.0 => False

L'expression est syntaxiquement correcte dans une tartine de langages, mais c'est fondamentalement une erreur technique de demander ça. Faut juste le savoir.

Et tant pis pour ceux qui le savent pas, z'ont qu'à apprendre.

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

Oui je me lâche un peu dans le troll, j'avoue :D

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

T'es nouveau dans la discussion ?

Bien sûr c'est inhérent à tous ceux qui utilisent IEEE-754, à savoir 90% des langages d'aujourd'hui, c'est justement ça que je soulève. On accepte tous ça connaissant la justification technique mais… perso je trouve que ça fait tâche.

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

Putain mais vous moinsez tout et n'importe quoi… il est pas rigolo mon exemple ?

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

A l'instant avec ce que j'ai sous la main :

Python 2.7.6 (default, Oct 26 2016, 20:30:19)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(2.0 - 1.8 - 0.2) == 0.0
False

Perso, je maintiens que c'est un bug. Là est peut-être le cœur du débat d'ailleurs.

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

Oui merci. Il "suffit" de demander au préalable à ne pas se tromper dans les soustractions.

2+2 => 5
pragma(te_vautre_pas_stp) 2+2 => 4

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

Oui oui c'était réellement pour rire que j'ai posté ça :-)

Manifestement il y a des sujets qui font pas rire ici, à voir la note de ton journal, ainsi que de mes post où je tente un "c'est vrai que c'est con quand même".

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

Donc pour vous, du moment qu'on n'arrivera jamais à faire une précision illimitée, on accepte une erreur d'une soustraction à 1 chiffre après la virgule.

Je ne parle pas d'un truc ultime qui fasse du calcul formel, je parle d'une expression de CM2. Tout le monde me dit (et à juste titre) "il y a des bibliothèques pour ça", donc la solution existe, oublions la justification du "le parfait n'existera jamais". La solution à mon pb existe AUJOURD'HUI.

Ma réflexion est sur le "par défaut".

A l'argument de la perfos (qui est le seul argument que je me prends en face donc) je réponds :
- en général on se fout de la perfo (là l'exemple a été donné en Python interactif quand même, c'est pas rien !)
- on peut toujours, pour ceux qui cherchent la perfo (ce que je soutiens c'est que c'est une large minorité) rebasculer vers le bon vieux IEE-machin (option de compil, déclaration dans le script du langage interprété ou je ne sais quoi)
- les CPUs augmentent de puissance, autant en profiter

1980, 2020, même combat : "2.0 - 1.8 - 0.2 != 0.0" dans un langage de programmation courant.

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

Les flottants ne sont pas parfaits, mais la précision est quand même grande

Oui oui, j'en conviens très très bien. Les cas où on en a réellement besoin sont rares, pas de soucis avec ça. Les FPU hardware ont révolutionné pas mal de trucs, et le passage en 64 bits explose tous les besoins… mais en attendant on se traîne un ridicule "2.0 - 1.8 - 0.2 != 0.0" (je préfère l'écrire sous cette forme : on ne parle plus de précision, mais d'erreur entre TRUE/FALSE).

Il peut faire langage de script, c'est avant tout un langage de programmation.

Pardon, langage interprété

Ce que tu ne comprends pas c'est qu'on parle de quelque chose par défaut.

Mais justement, c'est de ça dont je parle ! Quand basculera-t-on ? C'est peut-être pas si loin… on se traîne ce vieux truc pour des raisons de perfos uniquement. Un jour, on va quand même arriver à passer outre et à autoriser le signe "==" dans l'utilisation des flottants PAR DEFAUT dans des langages courants ?

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

Ah si, encore une tentative !!! Vous allez l'adorer :)

Ok, admettons, téléportons-nous qques instants dans un monde où 1000 en informatique c'est réellement 1024 (un peu d'effort d'imagination svp, j'ai ramé pour celle-là)

• C'est curieux quand même, quand je fais 1000*4 je me retrouve avec 4096
• Ah bin c'est normal, en informatique 1000 c'est 1024. Tu vois, pour multiplier par 1000, ça va plus vite en décalant de 10 bits, au lieu de se cogner le calcul (table de multiplications, ou additions successives). Et 2¹⁰ c'est 1024. Donc 4 * 1000 = 4096.
• Oui mais quand même, c'est faux.
• Mais ça prendrait trop de temps de faire de la multiplication en vrai ! Utilise un outil prévu pour ça (Excel par exemple). Mais avoue que la précision est suffisante.

Voilà, ça force le trait évidemment, mais c'est ça que j'observe : la justification de la représentation interne qui rend une erreur de calcul acceptable sous pretexte que ça va plus vite. Aujourd'hui, a-t-on encore besoin de ce "ça va plus vite" par défaut ?

Le même Python est passé par défaut en UTF8 en représentation interne. Il y a 10 ans, j'aurais dit "c'est quand même con de faire de l'ASCII par défaut, on a besoin couramment d'écrire autre chose que les 90 caractères de base", on me serait tombé dessus avec les même arguments (ça coute cher, c'est pas prévu pour etc. etc.) ?

Python est un bon exemple, c'est un langage de script, assez haut niveau, c'est une place parfaite pour activer une autre méthode de calcul (mais je n'attaque pas du tout Python en particulier, je pourrais dire la même chose soit avec des langages haut niveau style script, soit avec des langages modernes compilés très récents, modifiable par une option de compil bien évidemment)

Non ? Vraiment pas ?

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