Journal [Humour] vers un monde différent

Posté par reynum (site web personnel) le 18 décembre 2017 à 11:08. Licence CC By‑SA.

Étiquettes :

-15

déc.

2017

Je sais que beaucoup de nos certitudes ne sont que des visions de l'esprit et qu'avoir la sagesse de les remettre en question est l'une des qualités primordiales des scientifiques.
Mais si un jour on m'avais dit que :

$ python3.6
Python 3.6.3 (default, Oct  3 2017, 21:16:13) 
[GCC 7.2.0] on linux

>>> 2 - 1.8 - 0.2
-5.551115123125783e-1

Et bien je serais sûrement pêcheur en Martinique à l'heure actuelle :-D

# Pilule rouge

Posté par Aldoo le 18 décembre 2017 à 11:17. Évalué à 10.

https://fr.wikipedia.org/wiki/Virgule_flottante#Pr%C3%A9cautions_d'emploi

De rien.

(Sinon, attention au copié/collé : le résultat affiché est -5.551115123125783e-17 et non -5.551115123125783e-1, sinon c'est une sacrée erreur !)
# Rien de surprenant

Posté par Renault (site web personnel) le 18 décembre 2017 à 11:18. Évalué à 10.

Tu découvres simplement que les nombres décimaux non entiers ne sont pas représentables nativement par un ordinateur de manière exact. Pour des raisons d'optimisation, la quasi-totalité des langages de programmation (qui se basent sur le comportement du processeur) utilisent une représentation de ces nombres comme flottant qui n'ont pas une précision infinie.

Si tu veux faire des calculs avec une précision infinie, il y a beaucoup de bibliothèques (internes ou externes) pour le faire, mais le coût en calcul sera beaucoup plus important.
- [^] # Re: Rien de surprenant
  
  Posté par gUI (Mastodon) le 18 décembre 2017 à 11:57. Évalué à 0.
  
  mais le coût en calcul sera beaucoup plus important
  
  Faut reconnaitre que sur un exemple comme ça, ça fait tout de même tâche. Ce serait pas mal d'activer une bibliothèque en précision infinie par défaut. Ensuite, si tu fais un soft qui demande bcp de calculs, à toi de passer en flottant "natif", mais quand il s'agit d'additionner ou de soustraire des valeurs "simples", c'est dommage de tomber sur ça.
  
  Sinon Excel il fait comment ? C'est pas une blague : lui ne fait pas cette erreur, donc elle n'a rien d'évident ni de systématique cette erreur.
  
  En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
  - [^] # Re: Rien de surprenant
    
    Posté par Renault (site web personnel) le 18 décembre 2017 à 12:39. Évalué à 10.
    
    Faut reconnaitre que sur un exemple comme ça, ça fait tout de même tâche. Ce serait pas mal d'activer une bibliothèque en précision infinie par défaut.
    
    Pourquoi ?
    Je veux dire, c'est un langage de programmation, tout programmeur un minimum compétent doit savoir cette histoire de flottant, du moins dans le langage qu'il utilise.
    
    D'autant que la précision des flottants est suffisante pour la quasi totalité des usages.
    
    Sinon Excel il fait comment ? C'est pas une blague : lui ne fait pas cette erreur, donc elle n'a rien d'évident ni de systématique cette erreur.
    
    Excel est un logiciel, utilisé par des non informaticiens. Ils n'ont pas à se soucier de cette histoire de flottants. Python est un langage de programmation, ses utilisateurs doivent savoir ça car de toute façon cela se retrouve quasiment partout.
    - [^] # Re: Rien de surprenant
      
      Posté par gUI (Mastodon) le 18 décembre 2017 à 16:03. Évalué à 3. Dernière modification le 18 décembre 2017 à 16:04.
      
      Pourquoi ?
      
      Parce qu'on a inventé les ordinateurs pour calculer à notre place, et que maintenant qu'on a les moyens techniques qu'il fassent une soustraction de fin de primaire, il serait temps qu'ils le fassent sans se tromper, ne serait-ce à une erreur de 10^-17?
      
      Non mais je connais le truc, j'ai fait un IUT informatique, du IEEE-machin j'en ai bouffé. Mais 20 ans après… rien n'a changé, y compris dans un langage qui n'existait pas à l'époque[1]. On voit des chats qui tombent des chaises en fullHD sur Youtube, mais on fait toujours pas une soustraction de nombre difficilement représentables en binaire.
      
      [1] Wikipedia me dit que si, 2 ans avant que j'y rentre… bon, il doit sûrement se tromper :)
      
      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
      - [^] # Re: Rien de surprenant
        
        Posté par Renault (site web personnel) le 18 décembre 2017 à 16:16. Évalué à 9.
        
        Parce qu'on a inventé les ordinateurs pour calculer à notre place, et que maintenant qu'on a les moyens techniques qu'il fassent une soustraction de fin de primaire, il serait temps qu'ils le fassent sans se tromper, ne serait-ce à une erreur de 10-17?
        
        Pour quel coût ?
        Bien sûr que nos machines en sont capables, mais si tu ralentis la plupart des applications pour un gain nul, l'intérêt est discutable. De la même façon que de nombreux calculs en entiers normaux sont sensibles à l'overflow et d'autres effets du style également et peu de langages offrent une protection native contre cela.
        
        Mais dans la majorité des cas on s'en fout et le gain en performance est réel. Pour les quelques cas où la précision infinie (ou du moins très grande) est requise, le développeur a tout le loisir d'utiliser une bibliothèque (voire une extension du langage) pour que cela fonctionne.
        
        Car oui, je te l'assure, une précision aussi grande est vraiment rarement nécessaire.
        
        On voit des chats qui tombent des chaises en fullHD sur Youtube, mais on fait toujours pas une soustraction de nombre difficilement représentables en binaire.
        
        Si, on sait faire, mais il faut utiliser les outils adaptés pour.
        En tout cas il n'est pas déconnant qu'un langage de programmation use par défaut des nombres en virgule flottante. On s'adresse à des techniciens ou ingénieurs, pas à de simple utilisateurs qui eux en effet ne doivent pas voir ce genre de choses. C'est quand même différent.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 18 décembre 2017 à 22:44. Évalué à -9.
        
        Si, on sait faire, mais il faut utiliser les outils adaptés pour.
        
        Alors disons que par défaut, on n'utilise pas les outils pour, et c'est dommage. On a 1Go de RAM au poignet, on devrait arriver à faire 3 soustractions correctement sur un PC non ?
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Renault (site web personnel) le 18 décembre 2017 à 23:06. Évalué à 10.
        
        J'ai vraiment l'impression que tu fais semblant de ne pas comprendre.
        
        Ta remarque est légitime pour quelque chose qui fait un calcul pour l'utilisateur. Car ce dit utilisateur n'a pas à se soucier des mécanismes de la machine, il n'a pas à savoir ce qu'est un flottant, le développeur n'a pas à présumer à sa place de la précision souhaitée.
        
        Mais là tu parles d'un langage de programmation générique, qui ne met pas l'accent pour être utilisable par n'importe qui pour faire n'importe quoi. Pour des raisons de performances il utilise les flottants par défaut. Comme la quasi totalité des langages et processeurs à notre disposition utilisent les flottants, ce n'est pas quelque chose de surprenant. On peut dire aussi qu'un informaticien doit de toute façon connaître les bases des calculs de sa machine que ce soit les flottants mais aussi la représentation des entiers de base.
        
        Tu n'as pas su démontrer le gain de passer au tout multi-précision par rapport aux flottants. Car en réalité, la réelle nécessité du multi-précision est rare la quasi totalité des applications en ayant besoin s’accommodent très bien des flottants ce qui permet des calculs rapides mais aussi peu gourmands en énergies car le processeur s'en occupe pour toi avec des circuits dédiés et pas très gros. C'est tout bénéfique.
        
        Pourtant, on ne peut pas dire que la programmation n'évolue pas, typiquement l'UTF8 s'impose malgré ses contraintes par rapport à l'ASCII car le gain est évident. Et jusque là personne ne semble se soucier vraiment de la question des flottants car manifestement, il n'y a pas de besoin.
        
        Si après tout c'est si révolutionnaire, pourquoi tu ne propose pas ton correctif à Python pour le faire par défaut ? Tout le monde te suivrait.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 08:39. Évalué à -7.
        
        J'ai vraiment l'impression que tu fais semblant de ne pas comprendre.
        
        Mais… évidemment :)
        
        Je joue l'avocat du diable, je joue le mec qui se dit "mais au fait, ce truc est là depuis 40 ans… il n'y aurait pas mieux à faire au fait ?".
        
        Depuis l'arrivée des FPU, le flottant ne coûte quasiment plus rien, c'est très bien pour jouer en 120fps, mais pour taper 3 lignes sous Python en interactif en plus… il y a peut-être mieux à imaginer non ?
        
        "Patron, la même chose !"
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par louiz’ (site web personnel) le 19 décembre 2017 à 14:12. Évalué à 6.
        
        Si tu veux une calculette en console, en interactif, utilise bc
        
        % echo "2-1.8-0.2" | bc
        0
        
        Et laisse les flottant tranquilles, qu’on puisse avoir des logiciels qui rament pas pour rien.
      - [^] # Re: Rien de surprenant
        
        Posté par 2PetitsVerres le 18 décembre 2017 à 16:25. Évalué à 10.
        
        mais on fait toujours pas une soustraction de nombre difficilement représentables en binaire.
        
        Si, les ordinateurs savent le faire, il y a des logiciels de calcul/calculatrices qui vont te le faire. Mais python n'est pas une calculatrice, c'est un langage de programmation. Quelque part dans sa documentation, il est marqué que les nombres en virgule flottantes sont représentés suivant la norme IEEE754, et que les calculs faits avec ces nombres suivent les règles de calculs définies dans cette norme ou ailleurs dans des choses associées. Python ne fait pas ce qu'il ne dit pas faire, et il fait ce qu'il dit faire, se plaindre qu'il ne marche pas comme une calculatrice de base, c'est comme de se plaindre du fait qu'une poêle ne permet pas de faire bouillir de l'eau pour les pâtes.
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
      - [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 18 décembre 2017 à 16:26. Évalué à 8.
        
        et que maintenant qu'on a les moyens techniques qu'il fassent une soustraction de fin de primaire, il serait temps qu'ils le fassent sans se tromper, ne serait-ce à une erreur de 10-17?
        
        Un logiciel conçu pour faire des maths "formels" ne se trompent pas depuis des lustres.
        Un logiciel conçu pour faire des calculs rapidement ne se trompe pas non plus (10-17 n'état pas) une erreur, c'est juste, cf marge d'erreur)
        
        Le problème est que l'OP n'est pas conscient d'utiliser un outil inadapté à sa demande, c'est tout. Et si il a besoin, son besoin est répondu.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 18 décembre 2017 à 20:36. Évalué à -10.
        
        Oui acceptons que tous que "2.0 - 1.8 - 0.2 != 0.0" et pour ceux qui sont pas d'accords : RTFM.
        
        Perso, je trouve ça très moyen. Encore une sujet où on n'a pas avancé d'un iota depuis les années 80… c'est dommage.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 18 décembre 2017 à 21:44. Évalué à 5. Dernière modification le 18 décembre 2017 à 21:46.
        
        Bon, comment expliquer sans rire… Soyons sérieux et mettons-nous au niveau.
        
        Tu parles de RTFM quand une personne te répond que bon, utiliser un marteau-piqueur pour enfoncer un clou n'est pas terrible et qu'il vaudrait mieux utiliser un marteau; je ne connais pas de marteau-piqueur avec une alarme "attention, vous essayez d'enfoncer un clou avec un marteau-piqueur, vous allez avoir des surprises".
        
        ici, c'est pareil, tu demandes à une commande faite pour répondre à un besoin de calcul rapide sur des flotants de faire du calcul formel, et te plains que l'outil que tu testes, fait pour programmeurs (Python est un langage de programmation) ne fait pas de calcul formel par défaut, alors que pour du calcul formel on utilise une calculatrice. tu "oublies" au passage de constater que le résultat est juste (cf gestion des arrondis).
        
        J'espère t'avoir éclairé, mais je me demande quand même si tu dirais pas "Encore un sujet où on n'a pas avancé d'un iota depuis les années 80" si quelqu'un se plaint que le marteau piqueur ne marche pas bien pour enfoncer un clou… (version moderne : "Encore un sujet où on n'a pas avancé d'un iota depuis les années 2000" quand une personne se tue en faisant un selfie alors que le smartphone n'a pas empêché la personne de mourir? Ca devrait être évident pourtant pour le smartphone que la priorité est de sauver des vies et non pas de faire des selfies… Chiants les gens qui disent RTFM)
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 18 décembre 2017 à 22:39. Évalué à -9.
        
        Le marteau piquer pour taper sur un clou, c'est djéà fait depuis belle lurette : utiliser un CPU de plusieurs GHz pour faire 3 soustractions. Et il se trompe.
        
        Alors on peut accepter que l'ordinateur n'est pas fait pour calculer (ce que je me refuse à accepter, ne serait-ce que par son nom en Anglais), ou se dire "tiens, c'est curieux quand même qu'on soit pas fichus de faire mieux que 2.0 - 1.8 - 0.2 != 0.0".
        
        Mais bon, pas grave, je me fais pas comprendre (je dois mal m'expliquer), tout le monde s'évertue à m'expliquer ce que je sais déjà.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Psychofox (Mastodon) le 18 décembre 2017 à 23:54. Évalué à 10. Dernière modification le 18 décembre 2017 à 23:56.
        
        Ton ordinateur peut faire les soustractions sur des nombres décimaux et sans se tromper :
        
        ~> echo "2 - 1.8 - 0.2" | bc 0
        
        Faut juste utiliser l'outil pour.
        
        Tu ne te fais pas comprendre, tu fais exprès de faire semblant de ne pas comprendre dans une tentative puérile de gagner une stupide bataille de rhétorique.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 08:02. Évalué à -9.
        
        Oulah malheureux ! Méfie-toi !
        
        Je te fais la même chose en C et il me donne le même résultat. Pourtant c'est pas un vrai '0'. La preuve il me dit que le résultat est != 0. Alors je ne sais pas pour bc, mais il faut ne pas se limiter à l'affichage, et comparer le résultat avec 0.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Psychofox (Mastodon) le 19 décembre 2017 à 08:10. Évalué à 7.
        
        Pourquoi tu me parles du C.
        
        Lis la man page de bc :
        bc is a language that supports arbitrary precision numbers with interactive execution of statements.
        
        [...]
        
        Numbers
        
        The most basic element in bc is the number. Numbers are arbitrary precision numbers. This precision is both in the integer part and the fractional part. All numbers are represented internally in decimal and all computation is done in decimal. (This version truncates results from divide and multiply operations.) There are two attributes of numbers, the length and the scale. The length is the total number of significant decimal digits in a number and the scale is the total number of decimal digits after the decimal point. For example, .000001 has a length of 6 and scale of 6, while 1935.000 has a length of 7 and a scale of 3.
        
        [^] # Re: Rien de surprenant
        
        Posté par BAud (site web personnel) le 19 décembre 2017 à 14:19. Évalué à 8.
        
        Lis la man page de bc :
        
        quoi ?! un RTFM en 2017 ? Mais ça devrait être l'ordinateur qui s'adapte à ce qu'on lui demande, m'enfin !
        ;-)
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 14:35. Évalué à -1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par ®om (site web personnel) le 19 décembre 2017 à 14:24. Évalué à 5. Dernière modification le 19 décembre 2017 à 14:25.
        
        bc is a language that supports arbitrary precision numbers
        
        La preuve : quelles sont les 1000 premières décimales de π?
        
        $ n=1000;bc -l<<<"scale=$n;4*a(1)" 3.141592653589793238462643383279502884197169399375105820974944592307\ 81640628620899862803482534211706798214808651328230664709384460955058\ 22317253594081284811174502841027019385211055596446229489549303819644\ 28810975665933446128475648233786783165271201909145648566923460348610\ 45432664821339360726024914127372458700660631558817488152092096282925\ 40917153643678925903600113305305488204665213841469519415116094330572\ 70365759591953092186117381932611793105118548074462379962749567351885\ 75272489122793818301194912983367336244065664308602139494639522473719\ 07021798609437027705392171762931767523846748184676694051320005681271\ 45263560827785771342757789609173637178721468440901224953430146549585\ 37105079227968925892354201995611212902196086403441815981362977477130\ 99605187072113499999983729780499510597317328160963185950244594553469\ 08302642522308253344685035261931188171010003137838752886587533208381\ 42061717766914730359825349042875546873115956286388235378759375195778\ 18577805321712268066130019278766111959092164201988
        
        blog.rom1v.com
        
        [^] # Re: Rien de surprenant
        
        Posté par Marotte ⛧ le 18 décembre 2017 à 21:57. Évalué à 10. Dernière modification le 18 décembre 2017 à 21:57.
        
        Oui acceptons que tous que "2.0 - 1.8 - 0.2 != 0.0" et pour ceux qui sont pas d'accords : RTFM.
        
        Comme l’a dit Zenitram, il y a des outils pour faire du calcul formel. Je ne connais pas trop mais je pense que des logiciels/langages comme R ou Matlab permette de faire ça. Mais oui, définitivement, en informatique '1.8' représente généralement un nombre en virgule flottante, donc "2.0 - 1.8 - 0.2 != 0.0" (si on veut… car on a plutôt tendance à considérer que 5.511…e-17 égale zéro… en virgule flottante…)
        
        C’est comme le fait qu’en informatique, contrairement à toute les autres matières, un kilobyte ne vaut pas mille bytes. Je suis au courant pour la norme, récente, de 1kB = 1000B et 1kiB = 1024B, mais le premier informaticien qui utilise la base 10 pour ça je lui mets deux baffes !
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 18 décembre 2017 à 22:40. Évalué à -9.
        
        Comme l’a dit Zenitram, il y a des outils pour faire du calcul formel.
        
        Terme bien compliqué par parler de 3 soustractions non ?
        
        Je ne cherche pas une explication, je la connais depuis un paquet d'année, juste que je constate que… c'est quand même bof bof comme résultat non ?
        
        Vu de l'extérieur… 3 soustractions… une erreur de calcul… non ? Vraiment pas ? Vous trouvez ça normal ?
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 18 décembre 2017 à 23:16. Évalué à 7. Dernière modification le 18 décembre 2017 à 23:18.
        
        Vu de l'extérieur… 3 soustractions… une erreur de calcul… non ? Vraiment pas ? Vous trouvez ça normal ?
        
        Un truc que toi ne comprend pas : une calculatrice sait très bien faire ça. "Calc" sous Windows 9 le faisait déjà.
        Ce que tu n'arrives pas à comprendre, toi, c'est que l'outil utilisé est fait pour faire des calculs en virgule flottante, et que "0.2" n'existe pas en IEEE754 donc c'est arrondi.
        
        Tant que tu ne comprendras pas que "0.2" ne passe pas formellement en IEEE754, tu ne comprendras pas le problèmes.
        
        donc :
        
        Mais bon, pas grave, je me fais pas comprendre (je dois mal m'expliquer),
        
        Faux : tu n'arrives pas à comprendre.
        Tu inverses.
        
        tout le monde s'évertue à m'expliquer ce que je sais déjà.
        
        Faux : tu n'as toujours pas compris, tu ne sais pas.
        Tu penses savoir, et tu penses être le seul. Classique certes "moi je sais, les autres sont nuls".
        Donc au final une proposition : arrête de penser savoir déjà, et relis.
        
        Plus bas tu t'enfonces encore :
        
        Pourquoi accepter fatalement cette erreur de calcul (parce que ça en est une ?).
        
        Tu penses que le résultat est faux, alors qu'il est juste (le résultat est celui attendu de l'outil qui a été conçu pour sortir exactement ce résultat, qui rentre dans la marge tolérée pour considérer que c'est juste, ou 10 puissance -17 c'est pas loin de 0 et dans la tolérance acceptée de l'outil que tu as choisi).
        
        99,999% du temps on fait des trucs pas pressés donc le temps importe peu.
        
        Faut être quand même être un peu masochiste pour sortir Python pour faire ces calculs "99,999% du temps", 99,999% (voire 99,9999% attention ça s’arrondit à 100% mais 100% ne veut pas toujours dire unanimité, ça dépend de l’arrondi) des gens vont sortir la calculatrice de l'environnement de bureau ("calc" sous Windows) et pas un shell Python inadapté.
        
        Python fait ici ce qu'on lui demande (arrondir 0.2 en IEEE74 et calculer dessus, ressortir un résultat juste même si il ne te plaît pas), tu as juste du mal à comprendre que tu demandes un programme qui fait du calcul en flottant de faire du calcul formel on ne sait pas pourquoi.
        
        Poses-toi la question de savoir pourquoi tu veux absolument qu'une interface pour calcul flottant te fasse du calcul formel, et pose toi la question de pourquoi tu ne prends pas juste une calculatrice (même sous Linux) faite pour le calcul formel pour faire du calcul formel.
        
        Tu penses que le problème est chez les autres (trouver normal que le programme fasse ce pour quoi il est conçu c'est-à-dire du calcul flottant), alors qu'il est chez toi (ne pas comprendre qu'il faut utiliser une calculatrice pour faire du calcul formel)
        Bon, sinon oui je vais arrêter, de toutes façon tu ne veux pas comprendre et veux absolument que tous les autres aient torts (tu es le meilleur, excuse-nous). J'espère que ton chef ne te lit pas ici, car il se poserait des questions sur ta capacité à comprendre l'informatique, en plus des maths (et de ses limites, ce qu'on apprend au lycée je crois, à savoir qu'une règle qui indique "1 cm" n'est pas "1 cm" précisément mais avec une marge d'erreur car toutes les règles de lycéen ne sont pas faite avec une précision identique que celle utilisée pour faire un satellite à plusieurs millions d'€) et de savoir choisir les bons outils.
        
        Et zut, j'avais écrit essayer de ne pas rigoler, désolé j'ai craqué devant tant de blocage, j'ai écrit un pavé tellement on rigole à lire ce genre de bêtise (désolé, pas d'autre mot…).
        Bon, ce fût bénéfique : je te remercie, ça m'a détendu avant d'aller au lit de voir cette capacité à bloquer, même si on connaît depuis les années 80 (et avant) c'est toujours comme la première fois, merci donc (d'hab' j'essaye de ne pas rigoler des gens, mais la tu as cherché le bâton pour te faire battre, je comprendrai toutefois qu'on me moinsse pour me "punir" de cette bassesse).
        
        Note : le titre du journal est "humour", j'ose espérer que son auteur est au courant de la différence entre calculs sur des flottants et du calcul formel et que c'était juste une blague (bof), sinon ça serait de l'incompétence. A noter aussi que le mode par défaut de Python pourrait être débattu, pour pour être un minimum crédible dans la proposition de changer il faudrait commencer à ne pas dire que c'est un bug (car ce n'est pas un bug, c'est juste un choix par défaut différent de ce qu'on souhaite)
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 08:21. Évalué à -4.
        
        Alors déjà jusqu'à preuve du contraire, t'es autant bloqué que moi, puisque tu répètes comme moi les même choses en disant comme moi que j'ai pas compris :)
        
        Mais essayer de faire réfléchir différemment les gens, c'est pas facile.
        
        Ca fait 20 ans qu'on m'a expliqué que 2.0 - 1.8 - 0.2 est presque égal à zéro, et que "oh malheureux !" il ne faut pas essayer de comparer le résultat à zéro (ni à aucun autre valeur, jamais de "==" avec les flottants).
        
        Je le sais, je l'ai accepté, et je me suis même fait ma raison : de la même manière qu'un son analogique va être échantillonné parce que l'ordinateur ne sait pas gérer toutes les valeurs de la tension qui sort de ton micro, les mathématiques (qui pourraient être considérées analogique phylosophiquement) sont aussi "échantillonnées" car la précision infinie n'est pas possible (malgrès les bibliothèque que tu veux, elle n'est pas possible, il y aura toujours une limite). Donc en faisant cette soustraction, on prend la "valeur échantillonnée du monde mathématique" la plus proche. Et vu la précision des flottants, elle est fort acceptable pour le commun des mortels (peut-être Jésus aurait eu son mot à dire, mais là n'est pas le sujet).
        
        Là ce journal m'a fait un peu prendre de recul, c'est tout… relis mon premier commentaire, j'ai dit "ça fait tâche". Je comprends le débutant qui tape ces lignes, qui est super étonné alors qu'il n'avait jamais vu ça. On a beau avoir l'explication technique derrière, je reste sur ma première surprise en lisant ce journal "putain mais c'est vrai au fait".
        
        J'ai pas dit que c'est un scandale, qu'il faut réécrire tous les langages (comme on m'a judicieusement conseillé 2 ou 3x dans ce thread), j'ai juste dit que quand même ça fait bizarre quand on y pense, quand on se met à la place de celui qui ne sait pas ce que c'est que IEEE-machin (me souviens jamais du chiffre, mais je saurais les décoder en binaire je pense).
        
        Mais je le vis bien, je te rassure, je vais continuer à utiliser les flottants au quotidien (ou presque… j'avoue que mis à part dans les jeux, je dois pas être un grand consommateur de flottants) avec la grande satisfaction qu'ils me procurent aujourd'hui (j'ai fait du flottant sur 68000 sans FPU en faisant tourner des carrés, je sais ce que ça coûte).
        
        J'ai juste essayé de réfléchir un peu différemment de mon habitude, j'ai juste essayé de partager cette réflexion avec les autres, peine perdue, je me suis ramassé un wagon de "c'est comme ça épicétou".
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 19 décembre 2017 à 08:36. Évalué à 7. Dernière modification le 19 décembre 2017 à 08:37.
        
        J'ai juste essayé de réfléchir un peu différemment de mon habitude,
        
        Tu essaye surtout de faire du calcul formel à un outil volontairement fait pour faire autre chose que du calcul formel, il est 100% logique que les gens réagissent en te disant que tu te trompes juste d'outils.
        La question n'est pas du tout "réfléchir un peu différemment" : ta réflexion est banalement "j'ai envie d'utiliser un marteau-piqueur pour planter un clou, pourquoi pas? Bizarre le résultat quand même…", rien d'autre.
        tu n'as pas réfléchi différent, tu as juste dit une connerie (oui, dire "ça fait 20 ans qu'il y a ce problème" ou "il se vautre" quand le résultat est celui attendu donc pas un problème, et même pire il est juste car dans la marge de tolérance, c'est une connerie)
        
        A noter que "réfléchir un peu différemment" est pas mal utilisé par ceux qui pensent au créationnisme ou que la terre est plate, même argument.
        
        j'ai juste dit que quand même ça fait bizarre quand on y pense,
        
        La seule chose bizarre est de vouloir faire du calcul formel à un commande faite pour faire autre chose que du calcul formel, et de balancer "c'est un bug" quand l'outil fait exactement ce pour quoi il est conçu.
        
        "c'est comme ça épicétou"
        
        J'avoue ne pas réussir à comprendre comment tu arrives à t'auto-convaincre de ça, parce qu'en pratique personne n'a dit "c'est comme ça épicétou", on contraire tout le monde t'a expliqué la notion et dit que tu tordais un outil pas du tout fait pour.
        
        En pratique, quand une personne veut faire du calcul formel, elle utilise une calculatrice (oui, les gens sont assez intelligents pour ça). Passons, puisque tu veux absolument "réfléchir autrement" en trouvant bizarre qu'un outil fasse ce pour quoi il a été conçu… C'est rigolo un certain temps seulement ce genre de blague :). (j'arrive à me demander si tu ne fais juste pas exprès pour voir la tolérance des gens à la bêtise sous couvert de réfléchir différemment)
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 08:43. Évalué à -5.
        
        T'as raison, c'est plus rigolo, j'arrête aussi.
        
        Sinon, ça baigne ?
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par reynum (site web personnel) le 19 décembre 2017 à 08:49. Évalué à 4.
        
        j'ose espérer que son auteur est au courant de la différence entre calculs sur des flottants et du calcul formel et que c'était juste une blague
        
        Oui oui c'était réellement pour rire que j'ai posté ça :-)
        Tout était voulu à part la petite (mais énorme) erreur de copié collé pour le e-17
        
        il faudrait commencer à ne pas dire que c'est un bug (car ce n'est pas un bug, c'est juste un choix par défaut différent de ce qu'on souhaite)
        
        Je n'ai pas dis que c'était un bug. d'ailleurs j'utilise assez souvent round() pour les calcul sur float.
        
        kentoc'h mervel eget bezan saotred
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 10:41. Évalué à 1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par reynum (site web personnel) le 19 décembre 2017 à 13:56. Évalué à 5.
        
        Manifestement il y a des sujets qui font pas rire ici
        
        C'est comme la mayo, des fois ça prends pas :-D
        
        kentoc'h mervel eget bezan saotred
        
        [^] # Re: Rien de surprenant
        
        Posté par O'neam Anne le 19 décembre 2017 à 00:57. Évalué à 9.
        
        Je ne comprends pas : quand je tape sudo rm -rf /* ça supprime toutes mes données. C'est vraiment nul l'informatique ! Vous trouvez ça normal, vous, que je perde toutes mes données quand je tape juste une commande ?
        
        LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 08:31. Évalué à -5.
        
        Quand je vois ce style de contre argument : c'est clair, je ne me fais pas comprendre.
        
        rm -rf /* => dire à l'ordinateur d'effacer tout ce qu'il y a sous / => il le fait
        2.0 - 1.8 - 0.2 => dire à l'ordinateur de faire une soustraction => il se vautre (puisque le résultat est différent de zéro, c'est lui qui me le dit)
        
        Allez, aujourd'hui c'est moi qui sert de défouloir, moinsez-moi si ça peut vous soulager, j'ai du stock ;)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 19 décembre 2017 à 08:42. Évalué à 2. Dernière modification le 19 décembre 2017 à 08:43.
        
        Dit-moi, tu serais pas de ceux qui hurlent au complot quand un résultat sort genre "33% pour X, 33% pour Y et le reste 33%", car ça se voit il manque 1%! (non, il ne manque pas 1%… on a même dû faire une astérisque pour ceux qui ont du mal à comprendre)
        
        "dire à l'ordinateur de faire une soustraction" --> "dire à l'ordinateur de faire une soustraction en flottant, en acceptant le jeu des arrondis, sinon tu penses bien j'aurai utilisé une calculatrice si je voulais du calcul formel, faut être un peu idiot pour lancer une calcul flottant quand l'idée est du calcul formel"
        
        c'est clair, je ne me fais pas comprendre.
        
        Rein à voir : c'est clair, tu ne veux pas, toi, comprendre. Ta réflexion est dénuée de tout logique, pourquoi veux-tu que quelqu'un autre que toi puisse comprendre?
        
        Passons… C'est rigolo quelque temps, après c'est lassant.
        (mais j'avoue : je me suis marré à répondre, oui des fois il y a des amusements bizarres)
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 08:45. Évalué à -1.
        
        Ta réflexion est dénuée de tout logique
        
        C'est pas très gentil… :(
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marotte ⛧ le 19 décembre 2017 à 14:49. Évalué à 6.
        
        2.0 - 1.8 - 0.2 => dire à l'ordinateur de faire une soustraction => il se vautre (puisque le résultat est différent de zéro, c'est lui qui me le dit)
        
        Pour la énième fois : Non ! Tu demande à Python 3 de faire une soustraction. L’outil adapté pour faire ce genre de calcul en shell Unix c’est bc (ou encore dc), tu noteras que les deux donnent bien 0 comme résultat de la soustraction que tu as donnée.
        
        rm -rf /* => dire à l'ordinateur d'effacer tout ce qu'il y a sous / => il le fait
        
        Non plus. Depuis quelques années, toutes les bonnes distributions on un mécanisme en place pour demander une confirmation exceptionnelle pour exécuter cette commande :)
        
        aujourd'hui c'est moi qui sert de défouloir
        
        Tu fais surtout perdre du temps à tout le monde à troller comme un goret.
        
        [^] # Re: Rien de surprenant
        
        Posté par Antoine J. le 19 décembre 2017 à 19:57. Évalué à 5.
        
        Non plus. Depuis quelques années, toutes les bonnes distributions on un mécanisme en place pour demander une confirmation exceptionnelle pour exécuter cette commande :)
        
        En effet je viens de véri
        
        [^] # Re: Rien de surprenant
        
        Posté par Anonyme le 20 décembre 2017 à 02:49. Évalué à 5.
        
        Non plus. Depuis quelques années, toutes les bonnes distributions on un mécanisme en place pour demander une confirmation exceptionnelle pour exécuter cette commande :)
        
        Pas pour /*, seulement pour / :
        
        $ rm -rf / rm: il est dangereux d'opérer récursivement sur '/' rm: utilisez --no-preserve-root pour inhiber cette mesure de sécurité
        
        Par contre si tu utilises un shell digne de ce nom :
        
        $ rm test/* zsh: sure you want to delete all the files in /home/foo/test [yn]? n
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 09:25. Évalué à -3. Dernière modification le 19 décembre 2017 à 09:28.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Renault (site web personnel) le 19 décembre 2017 à 09:52. Évalué à 7.
        
        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 ?
        
        Les calculs des réels ce n'est pas gratuit. Dans l'idéal si tu ne peux avoir que des entiers, c'est le mieux. Je pense que tu n'as pas la moindre idée de l'impact de tout passer en multi-précision (de même pour les entiers au delà de 32 ou 64 bits, car oui tu oublies que la plupart des langages ne permettent pas des entiers plus grand nativement).
        
        Sinon ton histoire des 1000 vs 1024, c'est aberrant. Les flottants ne sont pas parfaits, mais la précision est quand même grande (assez pour être acceptable), là tu nous présentes une erreur de 2,5% sur des cas très courant, ce n'est pas la même chose !
        
        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.) ?
        
        Sauf que l'UTF-8, c'est utile à tout le monde par défaut. Car oui nos logiciels sont utilisés dans le monde entier, la contrainte linguistique est omniprésente aujourd'hui. L'ASCII n'est plus suffisant. On cherche encore en quoi le flottant est inadapté dans la majorité des cas (indice, ce n'est pas vrai).
        
        Python est un bon exemple, c'est un langage de script
        
        Il peut faire langage de script, c'est avant tout un langage de programmation. Il n'a pas été conçu pour remplacer ton shell.
        
        D'ailleurs tu noteras que les langages de scripts sont rarement pratiques pour faire des calculs en soi, car ce n'est pas leur rôle. Le shell est particulièrement pénible dans cet exercice.
        
        Non ? Vraiment pas ?
        
        Ce que tu ne comprends pas c'est qu'on parle de quelque chose par défaut. Python, comme d'autres langages, offrent des solutions natives pour faire ce que tu veux mais avec une syntaxe adaptée. Ils ont fait ce choix par défaut, qui est justifié et selon moi raisonnable. Ce n'est pas un bogue ou une erreur fondamentale d'avoir fait un tel choix. Cela est compatible avec leurs objectifs.
        
        Pour moi ta critique serait valable uniquement si Python se présente comme un langage de programmation destiné à découvrir la programmation (ce qui n'est pas le cas) ou si Python était une application destinée à des utilisateurs non formés (comme pourrait l'être ton tableur, ta calculatrice ou ton logiciel de comptabilité).
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 10:17. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par SpaceFox (site web personnel, Mastodon) le 19 décembre 2017 à 10:27. Évalué à 4.
        
        Quand basculera-t-on ?
        
        Probablement jamais ?
        
        Pourquoi aurait-on besoin de basculer, avec tout ce que ça implique en perte d'efficacité (vitesse de calcul et/ou efficacité énergétique), de problèmes de rétrocompatibilité, etc ? Pour quel avantage concret et chiffrable ?
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: Rien de surprenant
        
        Posté par Dr BG le 19 décembre 2017 à 10:30. Évalué à 3.
        
        Sans compter le fait que quelque soit le système choisi pour augmenter la précision, il y aura des calculs qui ne seront pas exacts. Si on compte sur le fait que deux variables représentant des réels sont censées être égales, on risque des bugs.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 10:37. Évalué à -2.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Dr BG le 19 décembre 2017 à 10:56. Évalué à 4.
        
        La solution à mon pb existe AUJOURD'HUI
        
        Elle existe pour cet exemple-là, mais tu trouveras toujours des exemples foireux.
        
        en général on se fout de la perfo
        
        Non, dans la majorité des cas, on s'en fout de plus de précision.
        
        [^] # Re: Rien de surprenant
        
        Posté par Dr BG le 19 décembre 2017 à 11:24. Évalué à 7. Dernière modification le 19 décembre 2017 à 11:28.
        
        Histoire de préciser ma pensée : je t'ai donné un exemple avec des décimales. Maintenant, tu fais
        >>> a = Decimal('1') / Decimal('3')
        >>> a - a
        Decimal('0E-28')
        
        Aïe, c'est pas 0, ça la fout mal. On a ralenti les perfs, et encore pour faire de la merde. Bon, les décimaux ça ne suffit pas, on passe au rationnels (en perdant encore de la perf aux passage) ? Ok, ça marche sur mon nouvel exemple, alors faisons un petit calcul similaire impliquant racine carrée de 2… zut, encore foireux. On s'arrête où ? C'est dommage de ne pas pouvoir faire des calculs sur les réels, mais c'est comme ça.
        
        [^] # Re: Rien de surprenant
        
        Posté par Renault (site web personnel) le 19 décembre 2017 à 10:59. Évalué à 5.
        
        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.
        
        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.
        
        D'autant que, si on veut être tatillon, comme l'a soulevé Zenitram, le calcul ici est au chiffre significatif 10^0, donc tout résultat dont la valeur entière est correcte est bonne. Même 0.9.
        
        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 !)
        
        Je pense qu'il est préférable que Python ait un comportement cohérent entre sa forme interactive et sa forme dans un fichier texte. Cela évite les surprises quand tu passes de l'un à l'autre, cela évite du code pour gérer cela et qui peut être source de bogues.
        
        La question est plutôt : qui utilise sérieusement son langage de programmation pour un calcul précis élémentaire ? Personnellement j'ai une calculette matérielle et une logicielle pour cela. Un langage de programmation n'est pas fait pour cela.
        
        Et non la performance on ne s'en fout pas, je pense que tu pleurerais si tout était en multi-précision. D'autant que tu oublies que ta logique voudrait qu'on transpose cela aux entiers car il est inadmissible que la quasi totalité des langages empêches l'usage d'entier supérieurs à 32 ou 64 bits sans syntaxe spécifique. Et étant donné l'importance des entiers dans tout logiciel et l'impact en performances que cela aurait, je pense que tu es content que les langages se conforment plutôt à ce que le processeur propose malgré les imprécisions. Car ces imprécisions sont suffisantes quasiment tout le temps. Aux autres de s'adapter un peu quand ils ont vraiment besoin d'une grande précision (sur entier ou flottant).
        
        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)
        
        Non ce n'est pas une minorité. Les flottants et les entiers étant partout dans tes logiciels, je pense sincèrement que tu regretterais une dégradation significatif des performances pour un gain en précision assez négligeable.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 11:55. Évalué à -6.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 19 décembre 2017 à 11:03. Évalué à 5. Dernière modification le 19 décembre 2017 à 11:06.
        
        La solution à mon pb existe AUJOURD'HUI.
        
        Une calculatrice, non?
        ton problème est juste un choix par défaut qui ne te plaît pas, c'est tout. Mais toi tu décide que tout le monde devrait être d'accord avec toi sur le choix par défaut on ne sait pas pourquoi (tu évites d'argumenter, un classique).
        
        on accepte une erreur d'une soustraction à 1 chiffre après la virgule.
        
        Il n'y a aucune erreur à 1 chiffre après la virgule : 10 puissance -17 c'est 0.0 à 1 chiffre après la virgule.
        C'est juste toi qui ne sait pas lire ni comprendre la signification de "à 1 chiffre après la virgule" que tu utilises.
        
        si tu veux que Python utilise le calcul formel par défaut, propose… Mais si tu commences à dire que l'actuel est faux, on va juste rire devant ton incompétence.
        
        1980, 2020, même combat : "2.0 - 1.8 - 0.2 != 0.0" dans un langage de programmation courant.
        
        Faux (cf plus haut, juste que tu as fais les arrondi ici mais pas demandé à Python de le faire, bizarre ta logique, à moins que ce soit de l'incompétence).
        
        Ha, zut, j'avais dit que j’arrêtais… L'humour ça va 5 minutes, l'auteur du post a lui-même dit qu'il connaissait, il y en a juste un qui continue à dire "bug" quand le problème est l'interface chaise-clavier.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 11:12. Évalué à -4. Dernière modification le 19 décembre 2017 à 11:13.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marco le 19 décembre 2017 à 11:26. Évalué à 4.
        
        Préviens aussi ceux qui font la norme C++ ils ont le même bug
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 11:33. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marco le 19 décembre 2017 à 12:49. Évalué à 4. Dernière modification le 19 décembre 2017 à 12:52.
        
        Il y a une infinité de nombre et tu voudrais tous les représenter.
        Pour augmenter ta précision tu dois augmenter le nombre de bits pour représenter tes nombres.
        Le système actuel permet d'avoir une grande étendue de nombre tout en ayant la possibilité d'avoir des chiffres après la virgule en ne prenant qu'un nombre limité de bit.
        
        La solution serait d'utiliser une virgule fixe soit :
        petit comparatif :
        
        Avec 32 bits en mode IEEE 754 je peux aller jusqu'à 10³⁸ (https://fr.wikipedia.org/wiki/IEEE_754)
        Avec 32 bits en entier (sans virgule) : je ne vais que jusqu'à 4 milliards
        
        Je veux une virgule fixe, on va dire que pour nos besoins qu'on a besoin que de 3 chiffres après la virgule on aura donc 10 bits pour représenter les chiffres après la virgule.
        Tu noteras que ce n'est pas optimisé (on perd le 0,1000 à 0,1024)
        Donc 22 bits pour coder l'entier ce qui donne 2²² = 4 millions et des brouettes (soit pas grand chose) avec seulement 3 chiffres après la virgule.
        
        L'(énorme) avantage de la mantisse+exposant c'est que le pas des nombre n'est pas linéaire : par exemple quand on est de l'ordre de 1 le nombre suivant est 1,00000012. Lorsqu'on est presque au maximum on est à 3,40282326×10³⁸ et maximum on est à 3,40282346×10^38.
        
        Parce que soyons honnête, y a très peu de cas ou différencier 4.000.000,381 de 4.000.000,379 est important voire on s'en fout de dire 4.000.000 ou 4.000.010, tout le monde va arrondir à 4 millions.
        
        Par contre c'est beaucoup plus intéressant de savoir différencier 0.0001 de 0.0002.
        
        Tout ça pour dire qu'en corrigeant ton problème avec des virgules fixe, tu t'impose également des limites.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 14:53. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Renault (site web personnel) le 19 décembre 2017 à 15:08. Évalué à 6.
        
        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 ?
        
        Car par défaut la précision des flottants suffisent et que la dégradation en performance serait trop importante.
        
        Tu oublies que les entiers sont aussi sensibles à des cas limites hein, dans ton esprit il faudrait aussi du coup utiliser des représentations natives au delà de 32 ou 64 bits. Tu te rends compte de la perte en perf par rapport au gain estimé ?
        
        J'ai l'impression que tu n'as aucune idée de l'impact de l'usage de non-flottants en terme de consommation mémoire et nombre de cycles nécessaires pour ces opérations.
        
        Autrement dit, par défaut, les neuneus se cognent une implémentation limitée mais ultra performante
        
        C'est qui le noeudnoeud ? Pour moi celui qui utilise python n'en est pas un car il est formé un minimum pour s'en servir et doit savoir quoi faire si cela lui pose un soucis.
        
        Dans le cas d'un logiciel destiné à un utilisateur final non informaticien de métier, oui l'implémentation devrait éviter cela nativement.
        
        je pense que vu les perfos actuelles des CPUs, on peut changer, oui…
        
        On parle quand même de plusieurs ordres de grandeurs plus lent, tu multiplies ça par la quasi-totalité des instructions de ta machine (car les entiers devraient logiquement être concernés). Bref, tu vas dégrader par un gros facteur X (probablement plus que 5-10) toute ta machine juste pour de la précision qui n'apporte rien ? Super !
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 15:36. Évalué à -5.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 19 décembre 2017 à 17:07. Évalué à 3. Dernière modification le 19 décembre 2017 à 17:12.
        
        les langages les plus utilisés aujourd'hui répondent que "(2.0 - 1.8 - 0.2) != 0.0".
        
        Le problème est que dans ta tête c'est vrai dans tous les cas. Ce qui est faux, même en pensant avec ta façon de faire.
        2.0 - 1.8 - 0.2 c'est (je n'y peux rien, c'est toi qui a mis une précision dans tes nombres) entre 1.9500… - 1.8499… - 0.2499… = -0.1499… et 2.0499… - 1.7500… - 0.1500… = 0.1499…
        0.0 c'est entre -0.0500… et 0.0499…
        Si tu suis, ton test d'égalité est parfois vrai, parfois faux, ça dépend (ça va être des probabilités).
        
        Même en jouant à la personne "qui connaît", tu te plantes royalement.
        
        Le plus gros problème est que tu as décidé qu'un système de calcul était le seul est unique utile (ou le plus utile) sans aucune argumentation sur le sujet, et tu te demandes pourquoi les autres ne sont pas d'accord avec ton choix 100% perso.
        
        J'ai pris une façon de faire des maths, tu en as pris une autre, les ordis qui gèrent des floats en ont encore une autre, et je ne te parle pas des arrondis bancaires tu aurais une crise cardiaque, ni des confs des CPU pour qu'ils changent de réaction dans les cas "spéciaux".
        Et tant que tu ne comprendras pas qu'il n'existe pas une "meilleure façon de compter", tu passeras toujours comme un idiot qui pense savoir de quoi il parle alors qu'il n'y connaît rien.
        
        J'ai un peu espoir tellement c'est gros que tu le fais exprès de vouloir passer pour la personne qui pense savoir de quoi il parle alors qu'il n'y connaît rien, juste pour le plaisir de troller. Le problème quand on joue à ça, c'est qu'on montre parfois son incompétence en réalité. L'auteur du journal s'est certes planté dans sa blague, mais au moins il est conscient que c'est le résultat attendu vu la commande qu'il a tapé (il a demandé un truc précis à la machine, qui a répondu comme elle est programmée pour répondre), c'était donc en connaissance de cause que c'est 100% normal et attendu (et voulu). Le journal est marqué humour.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 17:34. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par fearan le 19 décembre 2017 à 17:47. Évalué à 2.
        
        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.
        
        Mon prof de math justement, t'aurais mis 0, tu n'as pas indiqué la précision.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 17:57. Évalué à 1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par fearan le 20 décembre 2017 à 08:58. Évalué à 5.
        
        sauf que float != Decimal, un float est une représentation d'un nombre avec une précision (en python) de sys.float_info.epsilon.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 09:16. Évalué à -1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par fearan le 20 décembre 2017 à 09:45. Évalué à 6.
        
        j'avais oublié de préciser ±sys.float_info.epslion
        
        Encore 0, c'est ± 3*sys.float_info.epslion; et vu qu'on le stocke dans un 4^ème, c'est même 4 :D
        
        tiens, cadeau http://www.intellego.fr/soutien-scolaire-2nde/aide-scolaire-mathematiques/encadrement-valeur-approchee/32630
        
        Cours de seconde, valeur approchée, (la notion est aussi abordée en 4^ème)
        
        Globalement les opération décimales donnant un résultat décimal sont un sous ensemble très restreint, on a un peu plus de chance avec les rationnels, mais c'est aussi très limité.
        
        Toi tu voudrais que le système détecte que le nombre est décimal, change son type 'automagiquement' en décimal, et le fasse à chaque opérations (exit le pipeline), et tant pis pour les perf.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 09:51. Évalué à -2.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 20 décembre 2017 à 10:09. Évalué à 2.
        
        Tu ne comprends toujours pas ce que tu veux est impossible ?
        
        Je résume ce que tu veux: une calculatrice qui affiche un résultat correct quand on fait des +, des - et des * chez des décimaux de petite taille (disons compris entre $\epsilon=10^{-99}$ et $10^{99}$ ). (Tu es bien d'accord que $10^{-99}$ est un décimal puisqu'il vaut $0,00000\dots01$ avec 98 zéros)
        
        Eh bien, je vais te démontrer que ça n'est pas possible.
        
        En effet, lorsque tu vas calculer $0,1\times 10^{-99}$ tu voudrais que ça affiche un résultat correct c'est à dire $10^{-100}$ mais ça n'est pas possible car la valeur minimale positive est $\epsilon=10^{-99}$ .
        
        Tu vas me dire: il suffit de ne pas fixer de limite sur la valeur minimale, et je vais te répondre qu'il y en a forcément une: la limite que te fixe la capacité de ta machine. Attention, ceci aurait en plus un coût monstrueux (mémoire + temps de calcul), tout ça juste pour ressembler à ce que fait une calculatrice (qui de toute façon se foire évidemment sur des décimaux de taille inférieur à $\epsilon$ ).
        
        Dans tous les cas, tu n'obtiendras jamais ce que tu souhaites, et tu pourrais t'approcher un peu de ce que tu souhaites quitte à multiplier le coût énergétique d'un petit calcul par 1 million: ton idée n'est évidemment pas retenue par les gens qui bossent là dedans et qui ont donc conscience de l'absurdité et l'inutilité de ton souhait qui n'est que le reflet de ton incompréhension profonde des nombres (décimaux, rationnels ou réels comme tu veux).
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 10:38. Évalué à -1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marco le 20 décembre 2017 à 11:44. Évalué à 6. Dernière modification le 20 décembre 2017 à 11:46.
        
        Tu vois que ce que je veux est possible ?
        
        Je l'ai déjà autre part sur un autre fil mais ce que tu veux n'a pas d'intérêt car ça sous entend que tu as un pas fixe.
        
        Par exemple si tu t'arrêtes 3 chiffres après la virgule (c'est peut être plus en fonction du besoin) :
        tu peux représenter et différencier 2,000; 2,002 mais également 100,001 et 100,002
        
        En revanche il te sera impossible de différencier 0.0001 de 0.0002 (alors que y a un facteur 2 de différence entre les deux nombres)
        
        Y a-t-il un intérêt à différencier 100,001 de 100,002 -> aucun dans 99% des cas de toute façon la valeur est probablement déjà fausse (parce qu'en général on ne fait pas des calculs pour faire des calculs, on calcule des choses réelles : des relevés de température, un nombre de personnes)
        
        Y a-t il un intérêt de différencier 0.00014 de 0.00020 ? Oui car même si ta valeur mesurée est fausse, l'erreur d'arrondi peut augmenter significativement l'erreur.
        
        Tu seras capables de représenter des nombres totalement inutile (100,001 100,002) mais incapable de représenter des nombres qui peuvent être important.
        
        Avec float tu règle le soucis, le défaut de float c'est qu'il effectivement incapable de représenter certains nombre (par exemple 0.2 sera peut être 0.2000000000001 chiffre sorti de me chapeau) car le pas n'est pas linéaire et donc qu'on ne peut pas utiliser les égalités (mais tu peux tester des inégalités.
        
        Donc dans la réalité dans 99% tu veux que le pas ne soit pas linéaire
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 11:57. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 20 décembre 2017 à 11:54. Évalué à 4.
        
        Ada ne fera qu'une partie de ce que tu veux.
        
        Par exemple, en déclarant le bon type, il t'écrira bien 0.0 pour LE calcul dont tu me parles (car pas de multiplication qui nécessite de baisser la valeur du $\epsilon$ ).
        
        Mais tu m'as dit que tu voulais non seulement faire des + ou des - mais aussi des $\times$ sur des décimaux raisonnables. Et là je te dis que ça ne marchera pas, comme je te l'ai montré: c'est à dire que la règle de base en math: "un produit est nul ssi au moins l'un des facteurs est nul" deviendra fausse. Donc tes calculs exacts avec les décimaux tu peux aller te brosser.
        
        Et si tu tolères l'erreur à pourquoi ne la tolères-tu pas à $10^{-17}$ ?? C'est n'importe quoi de chez n'importe quoi.
        
        NON et NON et NON ce que tu veux n'est pas possible. Doit t-on t'en donner d'autres preuves ?
        
        Aucun langage, aucun ne système ne pourra faire ce que tu veux (à savoir ADDITIONNER et MULTIPLIER des décimaux sans faire d'approximation), tout au plus, tu pourrais le faire, modulo un coût énorme totalement stupide, dans les limites de la machine ce qui finalement n'a aucun intérêt puisque ça repousse exactement le même problème que tu as juste un peu plus loin pour un coût énergétique exorbitant.
        
        Ce que tu souhaites ne serait pas un progrès mais une régression, tant sur le plan technique (coût de calcul monstrueux) que sur le plan des idées car ça voudrait dire que l'humanité ne comprend plus rien aux bases de l'analyse numérique et qu'elle se met à vouloir faire des choses dont l'intérêt ne porte que sur une toute petite classe de nombres sans intérêt (certains petits décimaux) uniquement pour l'addition et l'addition (super le progrès !).
        
        Je te conseille une chose:
        
        Apprends ce qu'est un anneau, un corps, et va lire un cours de représentation des nombres en machine. Quand tu auras compris ces notions, tu diras moins d'idioties.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 11:58. Évalué à -4.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par kantien le 20 décembre 2017 à 12:27. Évalué à 5. Dernière modification le 20 décembre 2017 à 12:31.
        
        Je me dis aussi que vu que Python le fait déjà dans un autre cas
        
        C'est pas tout à fait cela, il a changé la sémantique d'un de ces opérateurs sur les int, à savoir l'opérateur /, qui avant calculait le quotient euclidien et qui maintenant calcule la division dans le type float (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).
        
        Si tu veux calculer formellement sur des fractions en python, il faut utiliser le module fractions.
        
        >>> from fractions import Fraction >>> # attention à bien utiliser des strings ... Fraction('2') - Fraction('1.8') - Fraction('0.2') Fraction(0, 1) >>> Fraction('3') * Fraction('5/3') Fraction(5, 1) >>> # avec les floats ça posera aussi problème ... Fraction(2) - Fraction(1.8) - Fraction(0.2) Fraction(-1, 18014398509481984)
        
        Pour avoir un jour un tel comportement par défaut, j'en doute : les besoins en calcul formel sur ce type de nombres sont trop rares (application de niche) pour en faire le comportement par défaut.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 13:56. Évalué à -1.
        
        (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.
        
        [^] # Re: Rien de surprenant
        
        Posté par kantien le 20 décembre 2017 à 15:37. Évalué à 7.
        
        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.
        
        Eh bien ce que tu souhaites exactement (par défaut) est profondément ridicule. Quitte à choisir une représentation pour avoir de l'exactitude dans les calculs et perdre du temps (inutile dans la quasi totalité des applications), autant choisir celles des fractions : avec les décimaux tu n'as même pas la structure de corps (c'est pas « stable » par division comme type de données).
        
        >>> from decimal import Decimal >>> i,j = Decimal(3), Decimal(5) >>> i * (j / i) Decimal('5.000000000000000000000000001') >>> (i * j) / i Decimal('5') >>> from fractions import Fraction >>> i,j = Fraction(3), Fraction(5) >>> i * (j / i) Fraction(5, 1) >>> (i * j) / i Fraction(5, 1)
        
        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 ?
        
        Et je t'ai répondu que ce n'est pas ce qu'il fait ! Il a juste changer la sémantique de l'opérateur / et son type de sortie. Avant / calculait le quotient euclidien et était de type int * int -> int, maintenant il calcule le résultat de la division en flottant et est de type int * int -> float. C'est juste un changement de sémantique (l'opérateur // étant là pour la division euclidienne) et non une adaptation au besoin de précision. Si vraiment, ils avaient voulu cela (ou s'ils le voulaient) il faudrait choisir le type Fraction en sortie et non le type Decimal.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 16:36. Évalué à -4.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par kantien le 20 décembre 2017 à 18:05. Évalué à 5.
        
        C'est même pire que ce que tu crois, il faudrait changer également l'inteprétation des littéraux.
        
        type(2.3) <class 'float'>
        
        Je t'explique pas les problèmes de retro-compatibilité s'il fallait les interpréter par des décimaux :
        
        type(2.3) <class 'decimal.Decimal'>
        
        il faudrait rajouter des float(...) partout dans le code existant :
        
        type(float(2.3)) <class 'float'>
        
        Ils n'ont pas déjà assez de problèmes avec le passage python 2.7 vers python 3 ?
        
        Si tu veux des décimaux et gérer manuellement tes arrondis (et des problèmes d'arrondis, tu en auras), il y a un module pour cela : decimal. Si tu veux du calcul exact sur des fractions (sans problèmes d'arrondis avec les opérations algébriques), tu as un module pour cela : fractions. Sinon par défaut, comme dans tous les langages, tu te retrouves avec des nombres à virgule flottante ce qui n'est pas sans raison.
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 18:51. Évalué à -4.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 18:00. Évalué à -1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par THE_ALF_ le 21 décembre 2017 à 07:39. Évalué à 3.
        
        Decimal résous bien tous les problèmes:
        
        >>> from decimal import Decimal >>> Decimal("1")/Decimal("3")*Decimal("3") Decimal('0.9999999999999999999999999999') >>> Decimal("1")/Decimal("3")*Decimal("3")-Decimal("1") Decimal('-1E-28') >>> 1/3*3-1 0.0
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 09:08. Évalué à 4.
        
        En fait gUI voudrait un système pour que certains petits décimaux ne soient pas arrondis lors d'additions/soustractions et voudrait que ça devienne une norme implémentée dans la plupart des langages courant.
        
        Je crois qu'il a compris que ça ne pourrait de toute façon pas marcher pour la multiplication et encore moins pour la division et que cela limite beaucoup l'intérêt de son souhait.
        
        Je crois qu'il n'a pas compris que ce qu'il demande est une précision infinie (définition même du résultat exact) parce qu'il la confond avec le nombre de chiffres affichés après la virgule. Du coup on ne sait pas trop ce qu'il souhaite (il semble vouloir des calculs exacts mais en fait pas tout à fait puisqu'il semble tolérer $10^{-99}$ (mais pas $10^{-17}$ si j'ai bien suivi, c'est assez flou je dois dire).
        
        Je crois qu'il n'a pas compris que son souhait ne concerne qu'une infime classe de nombres qui ont juste la fâcheuse tendance d'êtres plus "visibles" que d'autres dans certains cas précis d'utilisation qui nécessiteraient tout simplement le choix de BCD ou de la virgule fixe ou encore mieux :
        
        Je crois qu'il n'a pas compris que son "problème" peut juste être réglé comme le font les tableurs, par un formatage de l'affichage des résultats qui privilégierait un arrondi au décimal le plus proche (en espérant que cet arrondi soit effectivement plus proche du résultat souhaité avec tous les nouveaux problèmes que ça génère).
        
        Pourtant je crois qu'il voudrait que Python ne traite pas le problème au niveau de l'affichage, mais essaye, en interne, de créer un nouveau type pour représenter uniquement les décimaux du genre x=1.3 (provoque la création d'une instance x de son fameux type) et puis python devrait analyser (on ne sait pas comment il peut bien faire) les opérations faites sur x pour voir s'il doit passer à du float (sic !).
        Par exemple une opération banale du type x=1.3; x = (2*x)/x ferait passer de son type à du float (alors que le résultat sera juste un entier !). Et donc un print (x+ 1.0) ferait afficher 2.999999999999.
        
        Je crois qu'il n'a aucune conscience du coût écologique ni du coût technique de tels choix.
        
        Je crois qu'il n'a pas compris que sur le plan des "maths" ça ne règle aucun problème puisque le problème de l'exactitude des calculs faits qui semble être son souhait sur ses fameux décimaux ne sera toujours pas réglé (tout au plus il sera déplacé un peu plus loin).
        
        Mais il croit que ce qu'il propose serait un "progrès" informatique (je cite). Son manque de connaissances mathématiques est en fait le cœur de son "problème". Le qualificatif "troll" qui lui a été affublé plusieurs fois provient du décalage entre ces méconnaissances et son assurance à "critiquer" les solutions techniques que proposent l'informatique et l'analyse numérique au problème de la représentation des nombres en machine.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 09:20. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 16:45. Évalué à 3.
        
        En fait tu ne lis rien, ou tu ne comprends rien, ou tu ne veux rien comprendre. C'est pour ça que tu n'avances pas.
        
        1) Qu'est-ce qu'un groupe ? Qu'est-ce qu'un anneau ? Qu'est-ce qu'un corps ?
        2) Que sont les décimaux, les rationnels, et les réels ?
        3) Comment peut-on les représenter en machine ?
        4) Un système de calcul basé sur une machine de Turing (mémoire finie) peut-il manipuler les décimaux ? (les décimaux n'ont aucun intérêt mathématique en math au passage). Peut-il manipuler les rationnels, les réels ?
        5) Qu'est-ce que la précision relative ? Qu'est-ce que la précision absolue ?
        6) Plus informatique: quelle différence y a t-il entre le calcul interne et la sortie utilisateur ?
        7) Si l'utilisateur ne comprend rien à l'analyse numérique et qu'il croit encore qu'un ordinateur peut faire des calculs arithmétiques exacts avec + - * et / avec des décimaux, n'y aurait-il pas un moyen de lui pondre une sortie qui arrondit au décimal le plus proche pour qu'il puisse croire toujours en l'exactitude du résultat qu'il espère ? <----- c'est ça qui t'intéresse: retravailler la sortie utilisateur (comme le font bc, libreoffice, excel) pour que tu croies en "l'exactitude" des résultats donnés.
        
        [^] # Re: Rien de surprenant
        
        Posté par kantien le 19 décembre 2017 à 18:44. Évalué à 6.
        
        Mon prof de math justement, t'aurais mis 0, tu n'as pas indiqué la précision.
        
        Il écrit des nombres décimaux, ce sont des valeurs tout a fait acceptables dont on n'a pas besoin d'indiquer la précision (sinon on indique un intervalle).
        
        #install_printer Q.pp_print;; Q.(of_ints 2 3 * of_ints 3 4);; (* 2/3 * 3/4 = 1/2 *) - : Q.t = 1/2 Q.(of_string "2" - of_string "18/10" - of_string "2/10");; (* 2 - 1.8 - 0.2 = 0 *) - : Q.t = 0 Q.(of_int 2 - of_float 1.8 - of_float 0.2);; (* avec les float ça marche pas *) - : Q.t = -1/18014398509481984
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 19 décembre 2017 à 17:47. Évalué à 5. Dernière modification le 19 décembre 2017 à 17:48.
        
        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.
        
        OK, donc tu n'as pas dépassé la 3ème.
        Tu devrais te renseigner : la façon dont j'ai mis est une de celles utilisées par les humains. Ca leur permet appréhender des problèmes mathématiques plus complexes que ceux qu'on vois en 3ème.
        
        Rassure-moi : tu trolles pour le plaisir, tu te dévoileras un jour?
        Si ce n'est pas le cas, ce serait "gênant" (et ton prof de math t'aurais mis un zéro pointé).
        
        Bon, passons… J'ai quand même bien ri sur la notion que les humains auraient une seule façon de compter.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 17:58. Évalué à -3. Dernière modification le 19 décembre 2017 à 17:59.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marotte ⛧ le 19 décembre 2017 à 23:30. Évalué à 5. Dernière modification le 19 décembre 2017 à 23:33.
        
        Si c’était une question dans un contrôle portant sur la notion de virgule flottante tu aurais bien eu zéro (exactement) :)
        
        Tu utilises un outil qui calcule en virgule flottante, un langage de programmation, Python, pour faire un calcul qui se fait de tête, et le résultat qu’il te donne te chagrine, j’ai bien résumé ?
        
        Nous c’est le pourquoi de cette critique que nous ne comprenons pas. Un ordinateur ne peut pas représenter un ensemble infini avec sa mémoire finie. Pour les entiers, augmenter la mémoire occupée par chaque nombre « à la demande » c’est encore pas trop compliqué. Pour les décimaux, le faire « comme dans la réalité » est beaucoup plus complexe (et coûteux bien entendu), le calcul en virgule flottante est une quasi-obligation pour obtenir des résultats, si on veut plus de précision on augmente simplement l’espace mémoire de chaque nombre, ça reste « faux »… l’ordinateur n’a pas trop le choix. On peut parler d’IA tant qu’on veut, un ordinateur s’apparente à un boulier…
        
        Tu sais tout ça. Donc reconnais que ta remarque est idiote et passe à autre chose, ce sera ma suggestion.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 07:27. Évalué à -1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marotte ⛧ le 20 décembre 2017 à 10:25. Évalué à 4.
        
        Ah enfin ! tu te ranges du côté de la raison. C’est pas trop tôt ! ;)
        
        [^] # Re: Rien de surprenant
        
        Posté par Thomas Douillard le 20 décembre 2017 à 11:57. Évalué à 3.
        
        Tu veux quoi, que l’interpréteur tente de « simplifier » l’expression avant de la calculer ? T’as le moindre début de commencement d’idée de patch sur python ?
        
        Si c’est facile, envoie un patch et fait le accepter !
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 12:03. Évalué à -2.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Thomas Douillard le 20 décembre 2017 à 12:15. Évalué à 4.
        
        Arrête de troller et juste fait le. Ptete que si c’est dans la prochaine version de python tu auras gagné le respect de la communauté linuxfr.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 15:35. Évalué à 4.
        
        @gUI
        Ca fait plusieurs fois que je te réponds la chose suivante (l'as tu vu ?):
        
        La science a progressé et permet de démontrer qu'aucun système de calcul (formel ou non) basé sur les machines classiques ne peut répondre à ce que tu demandes. C'est la nature des nombres réels qui fait que c'est impossible.
        
        bc ne fait pas mieux mais tu ne le comprends pas (il fait des erreurs similaires sur des calculs tout aussi simples).
        Exemple:
        
        3*(1/3) .99999999999999999999
        
        Autrement dit, c'est le progrès scientifique qui permet de prouver qu'il n'y a aucun "progrès" possible dans la direction que tu souhaites.
        
        J'ai mis des guillemets autour de "progrès" car en fait, la science ne progresse pas dans l'illusion mais dans l'étude de la réalité.
        
        Si la conversation tourne au troll depuis une trentaine de commentaires c'est parce qu'il te manque des connaissances sur le concept de nombre réel et en particulier celui de sa représentation (nécessairement impossible) dans une machine de Turing. Donc tu écris des choses assez véhémentes sans te rendre compte que tu réponds à côté malgré la patience (relative) de tes interlocuteurs.
        
        Bonne journée à toi :)
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 15:39. Évalué à -3. Dernière modification le 19 décembre 2017 à 15:40.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Psychofox (Mastodon) le 19 décembre 2017 à 15:52. Évalué à 4. Dernière modification le 19 décembre 2017 à 15:53.
        
        'prétendre' != 'expliquer'
        
        (et pour le coup c'est vrai quelque soit le langage qui a cet opérateur)
        
        [^] # Re: Rien de surprenant
        
        Posté par Barnabé le 19 décembre 2017 à 17:29. Évalué à 3.
        
        C'est là que tu te trompes, bc ne répond pas
        
        (2.0 - 1.8 - 0.2) == 0.0
        
        il répond
        
        (2.0 - 1.8 - 0.2) == 0.0 à un chouia près
        
        Python te répond la même chose, c'est juste la taille du chouia qui change
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 18:39. Évalué à 4.
        
        @gUI
        
        Non bc fait aussi mal: la preuve il dit que 3*(5/3) = 4.999999999999
        Autrement dit il fait les mêmes bêtises que python (juste qu'il ne fait pas pour les mêmes nombres que Python).
        
        Je t'ai expliqué que la science DEMONTRE (c'est assez simple en plus) qu'on ne peut pas faire mieux que ce qu'on fait en terme de représentation des réels en machine et que, quelque soit le choix que tu fasses, tu te retrouveras avec des problèmes du même type. Tu lis ou tu lis pas les commentaires ?
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 18:46. Évalué à -1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 19 décembre 2017 à 18:58. Évalué à 4. Dernière modification le 19 décembre 2017 à 18:59.
        
        c'est 99% du temps ce que les gens veulent en fait (c'est ce que je soutiens).
        
        La est sans doute le problème : d'une tu soutiens qu'une autre façon de penser que la tienne est un bug (ce qui est factuellement faux), et de deux tu soutiens sans aucune démonstration que les utilisateurs Python veulent ta façon de penser (ce que tu ne démontres par aucun argument, comme par hasard).
        
        Rappel : ceux qui veulent faire ta façon de faire prennent dans 99.999% du temps une calculatrice (je vais argumenté : ils sont pas idiots, il prennent un outil fait pour le job, et en plus c'est disponible par défaut sur tout OS en mode graphique, elle est belle la vie), qui fait le job demandé, il ne te reste donc pas foule pour ton "99%".
        
        Résumé : tu a plein de préjugé, quasi aucune connaissance du sujet, mais sait (on ne sait pas comment et tu ne le démontres jamais).
        Bon, certes, un classique… Le pire est que tu es crédible d'y croire.
        
        bon, j'avoue que ça m'a amusé, mais l'amusement a ses limites, je te laisse à tes préjugés.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 19:13. Évalué à -2.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 19:30. Évalué à 5.
        
        Je ne parle pas de réels, mais de décimaux.
        
        Un décimal est un réel.
        
        Je ne parle pas de précision infinie, mais bien de 1.8 et 0.2
        
        Bah si tu n'autorises pas d'intervalle d'incertitude c'est bien que tu souhaites représenter EXACTEMENT 1.8 en machine donc que tu veux une précision infinie. Ton problème c'est que tu veux parler d'un sujet mathématique, mais que tu n'as pas les bases.
        
        Par exemple Python propose Decimal qui est très bien,
        
        Demande à ce module de te calculer 3.0 * (5.0 /3.0)
        On est d'accord que ce ne sont que des décimaux comme tu le veux hein ?
        On est d'accord que le résultat est évidemment 5.0 normalement hein ?
        Bah devine quoi ! Il se vautre ton module python. Et c'est normal pour les raisons qu'on t'a déjà expliquées 30 fois.
        La preuve en image:
        
        >>> Decimal (3.0)* (Decimal (5.0)/ Decimal (3.0)) Decimal('5.000000000000000000000000001')
        
        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.
        
        Les 3/4 des commentaires disent exactement ce que je dis mais tu ne les comprends visiblement pas. Les bibliothèques dédiées servent (avec une énorme lourdeur) à représenter des rationnels jusqu'à une précision liée aux capacités de la machine. Si ton téléphone devait calculer rien que ta géolocalisation avec ça, il n'aurait plus de batterie en 30mn ! En plus ça ne servirait à rien de géolocaliser au micron près sachant que ça provient d'une mesure à 10m près.
        
        De toute façon, il n'existe aucun système qui fasse ce que tu attends car on démontre que ça ne peut pas exister sur des machines de Turing (sauf pour gérer de "petits" nombres avec une usine à gaz) et comme en plus l'ensemble des décimaux n'est pas stable par la division, ça se vautrerait en terme d'affichage au premier quotient pas sympa.
        
        Y a un moment où il faut respirer, écouter, apprendre et se taire, rien que par respect pour ta propre personne. On dirait que tu ne veux rien de tout ça, c'est dommage pour toi.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 19:41. Évalué à -3. Dernière modification le 19 décembre 2017 à 19:44.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 19:47. Évalué à 5.
        
        Tu confonds la taille de la représentation en machine avec la précision.
        Si tu veux parler de maths et d'info, il te faut connaître les maths.
        
        L'opération 3.0 * (5.0 / 3.0) ne concerne que des décimaux et elle donne le décimal 5.0 en math. Pourtant elle se vautre avec le module decimal de python. CQFD. J'ai essayé d'être patient, ça ne sert à rien. Parle à toi même, convaincs toi, toi même de tes bêtises si ça te chante.
        Bonne soirée.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 20:19. Évalué à -5.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 20:30. Évalué à 5.
        
        Donc tu veux juste faire des additions et multiplications sur quelques décimaux pas trop grands. Car on est bien d'accord que tu ne pourras rien faire d'autre (pas de division, encore moins de racines carrées etc). C'est ça que tu veux faire ?
        
        Dans ce cas là, tu as plein de langages qui font ça très bien (Ada par exemple). Mais tu ne pourras quasiment rien faire sorti de +, - et * (pour des tout petits nombres) Genre même partager une somme d'argent en trois, en sept, en 9 etc, tu pourras pas… Très utile… Je doute que ça ait un quelconque intérêt au niveau informatique, sauf pour essayer de s'en sortir sur un forum où tu as refusé de comprendre de multiples intervenants qui t'on dit pourtant plein de choses intéressantes.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 20:53. Évalué à -4.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 21:26. Évalué à 7.
        
        Tu veux une calculatrice ne possédant que les touches +, - et * uniquement sur des décimaux de toute petite taille.
        
        Tu ne veux pas qu'on puisse diviser (sinon on est bien d'accord que ça ne pourra jamais faire ce que tu veux, j'espère que tu l'as compris). Avec ça tu ne peux même pas programmer la moindre résolution de problème de niveau supérieur au CE2.
        
        Rends toi compte de l'absurdité totale de ce que tu racontes s'il te plaît. Ne le fais pas pour nous, mais juste pour toi.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 21:43. Évalué à -6. Dernière modification le 19 décembre 2017 à 21:45.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 22:00. Évalué à -3. Dernière modification le 19 décembre 2017 à 22:01.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marotte ⛧ le 20 décembre 2017 à 00:12. Évalué à 6. Dernière modification le 20 décembre 2017 à 00:17.
        
        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.
        
        Python n’est pas fait pour apprendre les maths aux CE2. Pour les problèmes supérieurs ce n’est pas « faux » mathématiquement, c’est au contraire mathématiquement exact en virgule flottante…
        
        Le fait que tu ne comprennes pas pourquoi le fait que la grande majorité des langages, à commencer par ceux qui se réclament généralistes, utilisent la virgule flottante de manière stricte est assez inquiétant, il faut bien le dire. C’est bien parce que ça marche mieux comme ça (le résultat final est juste dans la précision demandée, et on est sûr que les « erreurs » d’arrondi ont eu lieu, donc sûr de la précision…) que l’on procède ainsi.
        
        Et pour finir, sur Python et la didactique, ce résultat, qui montre « l’erreur » d‘arrondi, peut aussi être vu comme un bon moyen d’aborder cette notion en mathématiques. L’humain aussi, quand il calcule avec sa petite tête et son stylo, à part des trucs simples comme ton exemple de départ, il va faire des arrondis.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 07:33. Évalué à -2.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Faya le 20 décembre 2017 à 18:48. Évalué à 7.
        
        Mais du coup, pourquoi Perl ("généraliste" et "pas fait pour apprendre les maths aux CE2") choisit son type rationnals par défaut (éliminant au passage le problème posé dans le journal)
        
        C'est une vraie question. D'autres se la sont posée : https://stackoverflow.com/questions/46840840/does-perl-6-performance-suffer-by-using-rationals-for-decimal-numbers
        
        Ça parle des performances avec, en prime, des liens vers les discussions sur IRC de Larry Wall mais je n'ai pas le niveau nécessaire pour tout saisir. Mais la question de gUI n'est ptêt pas si bête… Y'a visiblement moyen de faire autrement que float "dans certains cas".
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 22:24. Évalué à -1.
        
        Mais la question de gUI n'est ptêt pas si bête…
        
        Ah au fait, je t'ai pas remercié pour cette intervention, je le fais maintenant : merci :)
        
        Qu'est que j'ai pris dans la gueule en attendant… Entre ceux qui démontrent que c'est pas possible, ceux qui disent que c'est une hérésie, ceux qui annoncent l'apocalypse et ceux qui me disent que je ferais mieux de prendre une calculette pour faire une soustraction aussi simple…
        
        Alors qu'il suffisait de chercher ceux qui (inévitablement… c'est tellement ridicule une telle erreur dans une soustraction de CE2) s'étaient posé la même question avant.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marotte ⛧ le 19 décembre 2017 à 23:55. Évalué à 3.
        
        Ah si, bc fait mieux, c'est un fait.
        
        Tu peux utiliser awk, il donne -0 :)
        
        $ echo | awk '{printf "%f\n",(2.0 - 1.8 - 0.2)}' -0.000000
        
        (si quelqu’un sait comment éviter ce pipe je prends)
        
        [^] # Re: Rien de surprenant
        
        Posté par Boa Treize (site web personnel) le 20 décembre 2017 à 00:21. Évalué à 6.
        
        Tout simplement avec :
        awk 'BEGIN{printf "%f\n",(2.0 - 1.8 - 0.2)}'
        
        [^] # Re: Rien de surprenant
        
        Posté par Tonton Th (Mastodon) le 03 janvier 2018 à 13:52. Évalué à 2.
        
        On accepte tous ça connaissant la justification technique mais… perso je trouve que ça fait tâche.
        
        Ceux qui ne l'acceptent vraiment pas se décident un jour à créer leurs propres langages. Tu sais ce qu'il te reste à faire…
        
        [^] # Re: Rien de surprenant
        
        Posté par Zenitram (site web personnel) le 19 décembre 2017 à 11:35. Évalué à 2. Dernière modification le 19 décembre 2017 à 11:37.
        
        Perso, je maintiens que c'est un bug.
        
        Mais bien sûr qu'il y a un bug.
        Le problème est que tu n'as pas compris que le bug n'est pas dans Python (il faut ce que lui demande l'interface chaise-clavier) mais dans l'interface chaise clavier (qui a un bug, il a décidé d'utiliser des flottants d'une manière mauvaise en plus pour faire du calcul formel).
        Et tant que tu ne comprendras pas que le bug est dans l'interface chaise clavier, tu diras juste des bêtises.
        
        Note : dans la commande demandée à Python, False et True sont tous les deux valables. 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. Oui, toujours un problème de bug d'interface chaise clavier qui n'a pas implémenté la notion d'arrondi, sans doute un problème de programmation au lycée (l'interface chaise-clavier étant sensé avoir été programmée correctement à ce moment, sur la notion d'arrondis).
        
        Là est peut-être le cœur du débat d'ailleurs.
        
        Tout à fait. Pas de chance, le bug est trouvé, et n'est pas la où tu le penses.
        
        Et à force de répéter mille fois, ça rentrera peut-être : pour du calcul formel, 99.999% des gens utilisent un outil faisant du calcul formel et aucunement des floats (faudrait être masochiste pour ça).
        en pseudo-code: si langage formel demandé utilise module langage formel, sinon utiliser de floats. L'interface chaise-clavier est buggué sur ce test, je suis d'accord avec toi que ça fait tâche un tel bug, faudrait penser à le corriger (toi seul le peut, les autres ne peuvent rien à ce code-la).
        
        argh, tu m'as encore eu à rigoler de la mauvaise foi. J'essaye de me désintoxiquer pourtant…
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 11:44. Évalué à -2.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par 2PetitsVerres le 19 décembre 2017 à 13:02. Évalué à 4.
        
        Bon, allez, je vais accepter la fatalité : (2.0 - 1.8 - 0.2) == 0.0 => False
        
        Si tu t'attends à ce que ça fonctionne comme en maths, c'est mal parti. Il n'y a pas de symbole '==' en maths.
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 12:01. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 14:26. Évalué à 0.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par fearan le 19 décembre 2017 à 15:48. Évalué à 9.
        
        Honnêtement, tu l'aurais anticipé ?
        
        écris comme ça oui : la somme de 3 nombres arrondis n'est pas du tout équivalente à l'arrondi de leur somme. Prends 0.4, arrondis à 0, fait le trois fois tu as 0, fait l'arrondis à la fin tu as 1.
        
        Je commence à avoir de sérieux doute sur tes notions de math.
        
        >>> round( 0.1 + 0.1 + 0.1, 1) == round (.3,1) True
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 16:17. Évalué à -4.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Thomas Douillard le 19 décembre 2017 à 12:28. Évalué à 7.
        
        Tu peux toujours tenter de faire implémenter l’arithmétique des intervalles dans ton micropro si tu veux. Ou de la faire utiliser par défaut. Ah tiens d’ailleurs je découvre que ça a déjà été fait : http://standards.ieee.org/findstds/standard/1788-2015.html (si tu lis rien que l’abstract tu verras le standard ne couvre qu’un ensemble limité de problèmes posés)
        
        Au moins tu te retrouves avec un encadrement rigoureux de l’erreur, et c’est même utilisé pour résoudre des systèmes numériques : https://infoscience.epfl.ch/record/33624/files/EPFL_TH3155.pdf pour une thèse dans le domaine de la « propagation par contraintes numériques » si le sujet t’intéresse. Chap 16 de ce bouquin aussi : https://www.elsevier.com/books/handbook-of-constraint-programming/rossi/978-0-444-52726-4
        
        Mais le truc c’est que si tu fais ça, c’est un des compromis possible, tu te retrouves non plus avec une seule valeur dans le résultat du calcul, mais avec une intervalle de valeurs, ce qui peut être embarrassant pour le programmeur moyen. Ça demande aussi de se poser une question de précision dans la valeur que l’on veut atteindre, ce qui n’est pas toujours utile. Pire, ce n’est utile pas dans la totalité des cas sauf si on sait déjà que ça l’est ( https://en.wikipedia.org/wiki/Dynamical_systems_theory#Chaos_theory ), c’est à dire si on est dans une application particulière … . Bref, ça introduit de la complexité, qui est inhérente à certains type de calculs. On préfère souvent avoir une bonne approximation de pi que de faire planter un programme parce qu’on a rempli la mémoire sans savoir ou s’arrêter. Le plus important, ce n’est pas d’avoir un langage magique généraliste qui devine tout seul ce qu’il faut faire, c’est que l’utilisateur soit conscient que c’est un compromis, et que peut être ce n’est pas adapté dans son cas. Mais si il fait de la théorie du chaos, il devrait savoir à quoi s’attendre. C’est assez compliqué que python devine tout seul le bon compromis pour ce que l’utilisateur veut faire, simplement parce qu’il ne sait pas ce que l’utilisateur veut faire.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 14:31. Évalué à -2.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Psychofox (Mastodon) le 19 décembre 2017 à 11:33. Évalué à 4. Dernière modification le 19 décembre 2017 à 11:34.
        
        1980, 2020, même combat
        
        Et oui la cohérence entre les comportements et les conventions sont des choses importantes, surtout pour des languages de programmations.
        
        Du reste je trouve plus sain d'avoir un truc qui se comporte comme ça dès les "expressions de cm2" (au moins le débutant se pose la question assez tôt) mais dont les limites sont bien plus hautes. L'important ce n'est pas d'avoir une précision parfaite pour un calcul banal (que tu peux obtenir de toute manière en le demandant expréssément), mais d'avoir un comportement par défaut normé et attendu pour que l'on sache comment utiliser le langage. C'est le but de la norme IEE 754.
        
        Du reste la représentation des nombres en virgule flottante est un truc qu'on apprend très tôt à l'école donc ce n'est pas un concept très compliqué à comprendre.
        
        [^] # Re: Rien de surprenant
        
        Posté par 2PetitsVerres le 19 décembre 2017 à 12:59. Évalué à 4.
        
        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 ?
        
        Je vois bien l'ironie, mais je pense qu'en fait ce serait une vrai bonne idée de supprimer les opérateurs 'égal' et 'différents' pour les flottants. Je pense que les langages ne devraient pas compiler/générer une exception si l'on fait
        a == b; // avec a et b de type flottant
        Et uniquement permettre les opérateurs de comparaison tels que 'plus petit [ou égal]' et associés. (D'ailleurs certains d'outils d'analyse statique indiquent des défauts potentiels lors de l'utilisation d'égalité sur les flottants, même lorsque c'est autorisé par le langage)
        
        Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 13:46. Évalué à 1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 15:54. Évalué à 3.
        
        Non car pour donner le meilleur arrondi, il faut parfois user du test d'égalité. C'est pourquoi il faut laisser le test d'égalité possible.
        
        Par contre, celui qui programme et veut faire des maths doit apprendre ce qu'une machine peut et celle qu'elle ne peut pas faire. Elle doit aussi comprendre qu'il n'y a aucune solution à ce problème car on l'a démontré.
        
        En fait, la communauté scientifique a travaillé depuis 40 ans (voire plus) sur ces sujets et on en a tout simplement fait le tour sur les machines de Turing.
        Pour la faire simple, on démontre qu'avec les machines dont on dispose on ne peut pas faire mieux que ce qu'on fait actuellement.
        Un logiciel de calcul formel qui fait du calcul avec des réels ne fait d'ailleurs que ce que IEEE754 fait sauf qu'on peut fixer le nombre de bits de la mantisse et de l'exposant augmentant ainsi un peu le champ des possibles. Rien de plus.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 16:06. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par fearan le 19 décembre 2017 à 16:24. Évalué à 6.
        
        C'est pas demander la Lune quand même, si ?
        
        C'est juste casser des années de compatibilité mais à part ça non. Tu n'utilises pas les bons outils; et tu voudrais que le reste du monde change ses outils pour TON bon plaisir.
        
        Tu n'as pas l'air de comprendre qu'aujourd'hui, la précision est amplement suffisante pour la majorité des gens. Demande une précision supérieur, et tu va pourrir les perfs de pleins de soft pour un gain nul.
        
        Dans quel milieu tu as besoin d'une précision supérieur a 10^-15 ?
        
        round(2.0 - 1.8 - 0.2, 15) == 0.0 True
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 16:29. Évalué à -4.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marotte ⛧ le 20 décembre 2017 à 00:32. Évalué à 5.
        
        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 ?
        
        Ça cassera des programmes, mal écrits certes, mais ça cassera…
        
        Il me semble que PHP a bien joué à changer le comportement de ses opérateurs d’égalité de version en version et les gens étaient pas très contents…
        
        Une régression ? Une belle connerie surtout ! On a expliqué en long et en large pourquoi le comportement actuel était mieux… J’espère que maintenant ça va mieux pour toi et tes interrogations.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 16:26. Évalué à 2.
        
        C'est pas demander la Lune quand même, si ?
        
        La Lune c'est possible on y est allés.
        
        Mais ce que tu demandes (calcul exact chez les réels ou même chez les rationnels) c'est pas possible et on le démontre que c'est pas possible.
        On peut te créer des illusions (du genre travailler en système BCD) pour que les décimaux s'affichent la plupart du temps correctement, pas plus.
        mais dès que tu demanderas: 3*(5/3) il y a fort à parier que tu n'obtiennes pas 5 et si ça marche pour ça, pour d'autres calculs ça marchera pas.
        Par exemple, en bc, 3*(5/3) ne donne pas 5.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 16:34. Évalué à -4.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par kantien le 19 décembre 2017 à 18:05. Évalué à 1.
        
        Par exemple, en bc, 3*(5/3) ne donne pas 5.
        
        Mauvais système de calcul formel ⇒ changer système de calcul formel :
        
        Q.(print @@ of_int 1 * of_string "5/3");; 5/3- : unit = () Q.(print @@ of_int 3 * of_string "5/3");; 5- : unit = () let i = Q.(of_int 3 * of_string "5/3");; val i : Q.t = {Q.num = <abstr>; den = <abstr>} Z.(to_int (Q.num i), to_int (Q.den i));; - : int * int = (5, 1)
        
        Zarith :-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Rien de surprenant
        
        Posté par c^3 le 19 décembre 2017 à 22:10. Évalué à 1.
        
        Petite astuce ;-)
        
        # #install_printer Q.pp_print;; # Q.of_string "1/2";; 1/2
        
        The cake is a lie.
        
        [^] # Re: Rien de surprenant
        
        Posté par kantien le 19 décembre 2017 à 23:51. Évalué à 2.
        
        Oui, je l'ai trouvé après le pretty-printer. Je l'ai mis dans cet autre commentaire et celui-ci. C'est plus joli avec. ;-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Rien de surprenant
        
        Posté par Dr BG le 19 décembre 2017 à 10:06. Évalué à 5.
        
        >>> from decimal import * >>> Decimal('2') - Decimal('1.8') - Decimal('0.2') Decimal('0.0')
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 10:47. Évalué à -2.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 11:25. Évalué à -3.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par SpaceFox (site web personnel, Mastodon) le 19 décembre 2017 à 11:32. Évalué à 2.
        
        C'est la limite du comique de répétition : ce message est le 23ème que tu postes ici¹, soit plus du quart des commentaires du billet à toi tout seul.
        
        À un moment, ça lasse.
        
        Selon une recherche dans la page sur « Posté par gUI ». ↩
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 11:37. Évalué à -4.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par Thomas Douillard le 19 décembre 2017 à 13:26. Évalué à 2.
        
        Ça réussit pas trop à ton Karma. Ptete que ça n’amuse personne à part toi, en fait. Pas très sociable.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 14:21. Évalué à 1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par SpaceFox (site web personnel, Mastodon) le 19 décembre 2017 à 14:30. Évalué à 2.
        
        Ben, le gars qui trolle un peu et qui joue de la mauvaise foi, ça peut être drôle.
        
        Le gars qui insiste encore et toujours, jusqu'à poster plus de 30 messages parce que personne ne lui dit ce qu'il a envie d'entendre, c'est juste du troll toxique. Et ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        Ça n'est plus drôle mais chiant.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: Rien de surprenant
        
        Posté par Thomas Douillard le 19 décembre 2017 à 14:32. Évalué à 2. Dernière modification le 19 décembre 2017 à 14:32.
        
        Oh bah oui on a bien vu que tu jouais. On a même tenté de te suivre. Finalement, on sait pas très bien a quoi tu joues. C’est assez désagréables. Le Karma, c’est pas important, c’est très certainement pas un but d’en avoir. C’est pas pour ça qu’il ne véhicule pas des messages.
        
        J’imagine que si on ne t’as pas convaincu, c’est que tu as échoué dans son objectif, quel qu’il soit. À moins que tu ne cherches qu’à faire durer la discussion coûte que coûte. Tu parles d’un objectif intéressant …
        
        [^] # Re: Rien de surprenant
        
        Posté par Psychofox (Mastodon) le 19 décembre 2017 à 14:43. Évalué à 4. Dernière modification le 19 décembre 2017 à 14:46.
        
        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".
        
        Si l'intelligence artificielle peut être d'une grande aide un langage n'a pas vocation à deviner ce que tu veux. Ce serait même plutôt dangereux. Imagine les centrales nucléaires qui s'emballent ou les fusées qui partent à l'horizontale sur un quiproquo juste parce que t'as la flemme d'être précis.
        
        D'autre part le cas du 2 - 1.8 - 0.2 c'est un truc que tu ne rencontres typiquement pas dans une programme typique. En général t'as des variables qui sont assignées et après elles sont traitées. De diverses façon.
        
        [^] # Re: Rien de surprenant
        
        Posté par Dr BG le 19 décembre 2017 à 11:33. Évalué à 6. Dernière modification le 19 décembre 2017 à 11:34.
        
        Perso, je ne l'ai pas moinsé, mais il n'a aucun intérêt.
        
        Le calcul est sur des float, et donne le bon résultat dans l'arithmétique des flottants. Si tu veux utiliser des décimaux, il faut le dire, mais pourquoi les utiliser par défaut ? Après tout on veut peut-être des rationnels (encore plus lourd), ou carrément du calcul formel (encore vachement plus lourd) puisque tous les réels ne sont pas représentables.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 16:20. Évalué à -1.
        
        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.
        
        [^] # Re: Rien de surprenant
        
        Posté par flagos le 20 décembre 2017 à 12:30. Évalué à 2.
        
        D'ailleurs je viens de m'amuser a tester sous Libreoffice:
        
        Sinon sur le débat, je suis assez d'accord avec toi. C'est assez nul finalement de voir des reels écrits sur un nombre fini (et courts) de digits etre traités comme Pi ou exp.
        
        Je pense qu'il y a clairement quelque chose a faire du coté du langage, notamment passer sur du calcul avec des entiers. Et pour anticiper ce qui a deja été sorti, je ne vois pas en quoi dans ce cas les calculs sur des entiers serait plus lent que des calculs flottants.
        
        Après je pense que les concepteurs de langages se fichent un peu de ce genre de détails et lorsqu'ils reçoivent des données de type flottante pour une addition par exemple, c'est une opération qui est relégué au CPU et ils n'essaient pas spécialement d'être smart en essayant de les passer sur des entiers par exemple lorsque c'est possible facilement.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 20 décembre 2017 à 12:55. Évalué à 2.
        
        Le calcul fait interne utilise des floats et ne donne pas 0.
        Mais la configuration du tableur fait qu'à l'affichage il y a un algo pour dire "c'est suffisamment proche de 0 pour que j'affiche 0". Ce qui peut d'ailleurs être faux auquel cas on peut aussi avoir des surprises dans l'autre sens.
        
        Le tableur n'a pas de recette magique pour calculer, il fait comme tout le monde avec la FPU et il y a une surcouche derrière pour arrondir sur ce que veut "probablement" l'utilisateur.
        
        [^] # Re: Rien de surprenant
        
        Posté par flagos le 20 décembre 2017 à 13:44. Évalué à 3.
        
        Juste pour clarifier: je n'ai pas dit que LO faisait autrement, j'ai juste testé qu'il a donné le résultat attendu.
        
        Mais sinon, en quoi se ramener a des calculs sur des entiers, notament pour des operations simples où les flottants ne font que quelques digits, serait si compliqué que cela a faire ?
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 20 décembre 2017 à 14:11. Évalué à 2.
        
        Mais sinon, en quoi se ramener a des calculs sur des entiers, notament pour des operations simples où les flottants ne font que quelques digits
        
        Remarque 1: 0.2 occupe tous les digits en binaire (il n'a pas de développement fini en binaire).
        Remarque 2: la classe des nombres qui s'écrivent sous forme fini en binaire sont les nombre de la forme k / (2ⁿ⁾ et ces nombres dans le quotidien ne sont d'aucun intérêt pratique puisque nous travaillons tous en base 10.
        
        [^] # Re: Rien de surprenant
        
        Posté par Tonton Th (Mastodon) le 03 janvier 2018 à 14:43. Évalué à 3.
        
        je n'ai pas dit que LO faisait autrement, j'ai juste testé qu'il a donné le résultat attendu.
        
        Soyons un peu nuancé : il a affiché le résultat attendu.
        
        [^] # Re: Rien de surprenant
        
        Posté par claudex le 19 décembre 2017 à 12:21. Évalué à 3.
        
        il est pas rigolo mon exemple ?
        
        Non, pas du tout. Tu as l'air de trouver rigolo ce que les gens trouvent inintéressant voire pénible.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Années 80
        
        Posté par Arthur Accroc le 20 décembre 2017 à 06:43. Évalué à 10.
        
        Encore une sujet où on n'a pas avancé d'un iota depuis les années 80… c'est dommage.
        
        Je ne dirais pas ça. Au début des années 80, on utilisait couramment le format BCD, d’abord dans les calculatrices, beaucoup plus répandues que les ordinateurs, mais les processeurs d’ordinateurs avaient aussi des instructions natives pour les traiter (pas en virgule flottante, il n’y avait pas encore de FPU, mais même s’il faut décomposer une opération en virgule flottante en opérations sur des entiers, à un certain stade, il faut effectuer l’opération en entiers sur les mantisses et si elles sont codées en BCD, mieux vaut qu’il y ait des instructions qui traitent directement ce format !).
        
        Avantage du BCD : l’absence de surprise. Si un nombre semble tomber juste en décimal pour les humains (comme 1.8), c’est aussi le cas pour la calculatrice ou l’ordinateur. Si on fait 1/3, on obtient 0.3333… et on est conscient qu’on a une imprécision.
        
        Quand on allumait les ordinateurs grand public de l’époque (des ordinateurs 8 bits, pas des PC ; au début des années 1980, les premiers IBM PC coûtaient une fortune, ce qui les réservait aux professionnels), en une poignée de secondes, on se trouvait sous BASIC. Malheureusement, je n’arrive pas à me rappeler quelle pouvait être la représentation des nombres utilisée par les BASIC de l’époque (et je n’ai pas d’ordinateur 8 bits sous la main pour tester). Je ne serais pas surpris qu’ils aient utilisé systématiquement des flottants en BCD (et pas d’entiers), mais je peux me tromper…
        
        Si jamais j’ai raison là-dessus, il est inexact de dire qu’on n’a pas avancé depuis les années 80 sur le sujet qui t’intéresse (à savoir ne pas avoir des résultats imprécis en faisant des opérations sur des nombres qui nous semblent précis) : on a avancé… dans le mauvais sens.
        
        Enfin il y a des sujets ou c’est pire. Au début des années 80, tu allumais ton ordinateur de poche et quelques secondes plus tard, tu pouvais directement programmer (c’était bien sûr valable aussi pour les ordinateurs 8 bits pas de poche).
        
        Maintenant, ton ordinateur de poche permet de téléphoner, mais pour ce qui est de pouvoir le programmer, c’est beaucoup moins immédiat !
        
        Je ne dis pas qu’il n’y a pas un tas de trucs mieux que dans les années 80 (Internet…), mais même dans le domaine technologique, il y a quelques points sur lesquels on en a perdu.
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: Années 80
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 07:59. Évalué à -2.
        
        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.
        
        [^] # Re: Années 80
        
        Posté par Thomas Douillard le 20 décembre 2017 à 12:11. Évalué à 2.
        
        Euh non, du décimal tout court … pas besoin de coder les chiffres en binaire. Drôle d’idée.
        
        [^] # Re: Années 80
        
        Posté par Psychofox (Mastodon) le 20 décembre 2017 à 08:08. Évalué à 2.
        
        Maintenant, ton ordinateur de poche permet de téléphoner, mais pour ce qui est de pouvoir le programmer, c’est beaucoup moins immédiat !
        
        Mouais. Si tu actives la pile graphique tu ne tombes pas directement sur un shell mais tu l'optiens en 1 commande.
        
        Et bash, zsh ou powershell, ça reste de la programmation quoiqu'on en dise.
        
        [^] # Re: Années 80
        
        Posté par Arthur Accroc le 24 décembre 2017 à 00:30. Évalué à 6.
        
        Malheureusement, je n’arrive pas à me rappeler quelle pouvait être la représentation des nombres utilisée par les BASIC de l’époque (et je n’ai pas d’ordinateur 8 bits sous la main pour tester). Je ne serais pas surpris qu’ils aient utilisé systématiquement des flottants en BCD (et pas d’entiers), mais je peux me tromper…
        
        Un test avec des émulateurs plus loin (en espérant qu’on puisse leur faire confiance là-dessus), finalement non.
        
        En tout cas les BASIC du Commodore 64 et de l’Amstrad CPC (difficile d’être complètement sûr pour les autres sans les essayer) utilisent tous deux des flottants :
        
        Accessoirement, vous remarquerez au passage comme l’émulateur de C64 fait un effort pour rendre la euh… « netteté » des écrans de l’époque…
        
        Sinon, vous remarquerez aussi que les erreurs sont du même ordre de grandeur… mais différentes. Signe d’une époque où tout n’était pas standardisé (processeurs, flottants…).
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: Années 80
        
        Posté par jnanar (site web personnel) le 24 décembre 2017 à 12:07. Évalué à 2.
        
        Sinon, vous remarquerez aussi que les erreurs sont du même ordre de grandeur… mais différentes. Signe d’une époque où tout n’était pas standardisé (processeurs, flottants…).
        
        2 -1.8 - 0.2
        -5.551115123125783e-17
        
        En l’occurrence, le 1E-17 est plus petit de 7 ordres de grandeurs que 2E-10 (si on prend en compte les valeurs absolues des résultats).
        
        Sinon, merci à tous pour ce superbe troll de Noël.
        
        snowball a fourni des réponses très instructives. N'étant pas dans le domaine, c'était très enrichissant.
        
        gUI en tenant son rôle de borné qui fait semblant de ne rien comprendre a berné tout le monde. Ça devenait un peu gros à la fin mais sinon, je pense que beaucoup de monde s'est laissé avoir par le réalisme du troll.
        
        [^] # Finalement…
        
        Posté par Arthur Accroc le 24 décembre 2017 à 13:40. Évalué à 3.
        
        En l’occurrence, le 1E-17 est plus petit de 7 ordres de grandeurs que 2E-10 (si on prend en compte les valeurs absolues des résultats).
        
        En effet, mais on ne peut pas vraiment s’étonner qu’à l’époque des machines 8 bits, on utilisait des flottants plus petits (donc moins précis) qu’avec les machines 64 bits actuelles (je dis « on utilisait », parce qu’il n’y avait pas de FPU, les calculs en flottants devaient être codés avec des instructions sur les entiers).
        
        Quoiqu’entre les deux, la FPU historique des processeurs Intel (x87) utilise des flottants plus gros (80 bits dont 64 de mantisse) donc plus précis que le moderne jeux d’instructions SSE2 (64 bits) !
        De nos jours, c’est la vitesse qui compte, la précision passe au second plan…
        
        gUI en tenant son rôle de borné qui fait semblant de ne rien comprendre a berné tout le monde. Ça devenait un peu gros à la fin mais sinon, je pense que beaucoup de monde s'est laissé avoir par le réalisme du troll.
        
        Sauf que finalement, en installant le paquet mpdecimal (nom sous Arch), j’obtiens des temps d’exécution similaires à ceux de gUI, c’est-à-dire un temps d’exécution avec le type Decimal très proche de celui avec les float (si j’exécute plusieurs fois, les temps varient, entre 2 et 50 % de plus pour le code en Decimal — pour plus de précision, il faudrait modifier le code avec un nombre d’itérations plus gros et fixe pour ne pas être influencé par les imprécisions des flottants). Le facteur 50 ou 60 était manifestement dû à l’utilisation de fonctions de secours en code pur Python.
        
        Et là, ça remet tout en cause…
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
      - [^] # Re: Rien de surprenant
        
        Posté par Michaël (site web personnel) le 21 décembre 2017 à 10:28. Évalué à 5.
        
        Non mais je connais le truc, j'ai fait un IUT informatique, du IEEE-machin j'en ai bouffé. Mais 20 ans après… rien n'a changé, y compris dans un langage qui n'existait pas à l'époque[1]. On voit des chats qui tombent des chaises en fullHD sur Youtube, mais on fait toujours pas une soustraction de nombre difficilement représentables en binaire.
        
        Les nombres en virgule flottante servent à faire du calcul scientifique, si on veut faire de l'arithmétique exacte il faut utiliser une autre structure de données.
        
        Par nature le calcul scientifique est un calcul approché parcequ'on passe son temps à calculer des quantités qu'on ne sait pas calculer de façon exacte, à commencer par les valeurs de la fonction exponentielle ou les racines.
        
        Choisir les structures de données adaptées au problème qu'il veut résoudre – et plus généralement les langages et outils – fait partie des compétences et du métier de programmeur et j'ai bien du mal à comprendre ce qui déplaît?
        
        Il y a des langages qui privilégient l'arithmétique exacte sur le calcul en virgule flottante tant que c'est possible (Common Lisp) mais ce n'est un choix raisonnable que si le langage permet d'une manière ou d'une autre d'insister pour que tel ou tel calcul soit bel et bien exécuté en virgule flottante et beaucoup de langages n'ont pas fait ce choix.
    - [^] # Re: Rien de surprenant
      
      Posté par Kwiknclean le 18 décembre 2017 à 17:23. Évalué à 2.
      Excel est un logiciel, utilisé par des non informaticiens. Ils n'ont pas à se soucier de cette histoire de flottants. Python est un langage de programmation, ses utilisateurs doivent savoir ça car de toute façon cela se retrouve quasiment partout.
      
      L'exemple de python comme calculatrice est présent dés le premier chapitre dans tout les tutoriels de débutants, le présentant comme une calculatrice puissante.
      
      Python s'est d'ailleurs imposé comme le langage d'étude pour les débutants. Parfois dés le collège. Je ne sais pas où ils en sont dans les programmes mais il me semble que la gestion des entiers/virgule flottantes par les ordinateurs, les normes IEEE 754, l'architecture des ordinateurs et tutti aux 4eme/3eme ça arrive un peu après Pythagore.
      
      Python est également utilisé par des non-informaticiens, beaucoup de chimistes/bio-chimistes, ou simplement des autodidactes (l’apprentissage est ouvert à tous faut pas être sectaire).
      - [^] # Re: Rien de surprenant
        
        Posté par Renault (site web personnel) le 18 décembre 2017 à 17:53. Évalué à 8.
        
        L'exemple de python comme calculatrice est présent dés le premier chapitre dans tout les tutoriels de débutants, le présentant comme une calculatrice puissante.
        
        C'est juste pour tester la bête, pas pour en faire une véritable calculatrice. Nul part j'ai vu que Python était présenté comme une véritable calculatrice.
        
        Car tu sais, dans la quasi-totalité des tutoriels, parmi les premiers TP tu as justement la fameuse calculette. Je ne connais aucun de ces langages qui gèrent nativement les nombres décimaux non flottants ou la gestion des overflow des entiers.
        
        Bref, ce sont des exercices, des exemples, pas un usage normal du langage.
        
        Python s'est d'ailleurs imposé comme le langage d'étude pour les débutants. Parfois dés le collège. Je ne sais pas où ils en sont dans les programmes mais il me semble que la gestion des entiers/virgule flottantes par les ordinateurs, les normes IEEE 754, l'architecture des ordinateurs et tutti aux 4eme/3eme ça arrive un peu après Pythagore.
        
        Personnellement je ne suis pas favorable à l'apprentissage du code (du moins d'un langage réel) avant le supérieur voire le lycée. Je ne pense pas que cela soit le plus important pour appréhender le numérique (d'autant que la majorité d'entre eux ne coderont pas). Il y a des langages adaptés pour les enfants ou adolescents, car sinon tu dois aussi expliquer ce qu'est un overflow, la gestion des erreurs, etc. Tu peux aller très loin si tu souhaites éviter qu'ils aient des surprises.
        
        Python est également utilisé par des non-informaticiens, beaucoup de chimistes/bio-chimistes, ou simplement des autodidactes (l’apprentissage est ouvert à tous faut pas être sectaire).
        
        Personne n'est sectaire, mais il faut réaliser qu'un langage de programmation ça reste un outil puissant mais qui a besoin d'une certaine expérience ou formation pour l'utiliser convenablement.
        
        Pour les scientifiques, je pense qu'un petit mot dans leur livre de formation indiquant que les nombres décimaux n'ont pas toujours une représentation exacte suffit et indiquer quoi faire s'ils veulent une précision infinie. C'est tout.
        
        Tu sais, cela me fait penser aux sciences qu'on enseigne à l'école. À la base, une racine carrée d'un nombre négatif, on t'enseigne que tu ne peux pas le calculer. Puis peu à peu tu apprends que si, pas dans R évidemment mais que tu peux en tirer quelque chose avec les nombres complexes. C'est pareil en physique où il y a des tonnes de simplification pour les gamins (Newton universel) avant finalement d'étudier les cas limites et que les simplifications ne fonctionnent plus.
        
        Je ne vois pas pourquoi en informatique il en serait autrement, c'est un outil, qui nécessite des compétences et beaucoup de formation. C'est bien de simplifier, de rendre le sujet plus accessible, mais ne pas oublier que nos processeurs ont de quoi calculer des flottants très vite pour peu d'énergie. C'est bon de l'exploiter. Tâche éventuellement à des langages plus orientés débutants (Python n'a pas ce but) de cacher ce genre de choses.
        
        [^] # Re: Rien de surprenant
        
        Posté par Kwiknclean le 18 décembre 2017 à 21:46. Évalué à 2.
        
        Personnellement je ne suis pas favorable à l'apprentissage du code (du moins d'un langage réel) avant le supérieur voire le lycée. Je ne pense pas que cela soit le plus important pour appréhender le numérique (d'autant que la majorité d'entre eux ne coderont pas). Il y a des langages adaptés pour les enfants ou adolescents, car sinon tu dois aussi expliquer ce qu'est un overflow, la gestion des erreurs, etc. Tu peux aller très loin si tu souhaites éviter qu'ils aient des surprises.
        
        Sur ce thème nous sommes d'accord, j'ai des doutes sur l'intérêt réel de faire du "numérique" si tôt dans la scolarité. A ce propos je ne sais pas s'il s'agit d'une légende urbaine mais j'ai maintes fois ouïe dire que les cadres sup' des GAFAM, faisaient très attention à placer leur rejeton dans des établissements à l'apprentissage traditionnel cahiers/crayon, bien loin du numérique.
        
        [^] # Re: Rien de surprenant
        
        Posté par Thomas Douillard le 19 décembre 2017 à 12:31. Évalué à 3.
        
        Tu sais, quand on fait des maths on fait aussi du « numérique » ;) le rôle de l’apprentissage c’est de démystifier ces machines qui font des maths. C’est une manière d’apprendre les maths d’ailleurs.
        
        [^] # Re: Rien de surprenant
        
        Posté par Renault (site web personnel) le 19 décembre 2017 à 13:02. Évalué à 4.
        
        A ce propos je ne sais pas s'il s'agit d'une légende urbaine mais j'ai maintes fois ouïe dire que les cadres sup' des GAFAM, faisaient très attention à placer leur rejeton dans des établissements à l'apprentissage traditionnel cahiers/crayon, bien loin du numérique.
        
        Mouais, je suis presque sûr que c'est plus lié au fait que les cadre sup' de ces boîtes, surtout au Royaume-Uni et aux USA, essayent de placer leurs enfants dans les meilleures écoles possibles qui sont souvent de grandes institutions privées avec des méthodes traditionnelles. C'est rarement là bas que tu verras les expérimentations du numérique à tout va, et les résultats sont bons grâce à la sélection à l'entrée et à des profs très compétents et avec des moyens pour les avoir et entretenir l'infrastructure scolaire.
        
        Quand bien même ce serait une volonté pour eux que leurs enfants évitent le numérique, cela ne rend pas la justification correcte.
  - [^] # Re: Rien de surprenant
    
    Posté par Boa Treize (site web personnel) le 18 décembre 2017 à 13:04. Évalué à 7.
    
    Sinon Excel il fait comment ? C'est pas une blague : lui ne fait pas cette erreur, donc elle n'a rien d'évident ni de systématique cette erreur.
    
    C'est plutôt l'inverse : « l'erreur » (qui n'en est pas une) est standard, évidente et systématique. Excel (malgré toutes les critiques qu'on aime lui faire) a certainement plein d'algorithmes compliqués / bien pensés / débogués pendant des années pour gérer ces cas.
    
    De même pour les calculatrices de poche, il y a un énorme travail de mathématicien derrière pour s'assurer qu'elles sont correctes, et jamais d'absolue certitude. D'ailleurs je suis certain que le cœur de calcul de ces machines évolue très peu une fois mis au point, et que les fabricants le déclinent pendant des décennies ensuite.
    
    Et le fait qu'Excel ou des calculatrices n'affichent pas cette erreur ne les rend pas exempts de bugs. Par exemple : https://forum.hardware.fr/hfr/WindowsSoftware/Logiciels/microsoft-excel-grosse-sujet_164758_1.htm (et j'en ai d'autres en mémoire, mais sans le détail).
    - [^] # Re: Rien de surprenant
      
      Posté par gUI (Mastodon) le 18 décembre 2017 à 15:53. Évalué à 3.
      
      je suis certain que le cœur de calcul de ces machines évolue très peu une fois mis au point
      
      J'ai lu récemment que les Z80 sont encore produits et se vendent encore car ils sont très présents dans les calculatrices de poche :)
      
      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
    - [^] # Re: Rien de surprenant
      
      Posté par dj_ (site web personnel) le 18 décembre 2017 à 16:16. Évalué à 4. Dernière modification le 18 décembre 2017 à 16:18.
      
      D'ailleurs c'est un des reproche qu'on pouvait faire pour la calculette Numworks (opensource et openhardware), mais c'est maintenant corrigé article de nextinpact en accès libre
      
      Dans les "bugs" d'excel, il y aussi la correction automatique. Qui a faussé des recherches en génétique article sur silicon
      
      Edit : Pour numworks, je suis grillé par bobo38 plus bas
  - [^] # Re: Rien de surprenant
    
    Posté par flavien75 le 18 décembre 2017 à 13:05. Évalué à 10.
    Sinon Excel il fait comment ? C'est pas une blague : lui ne fait pas cette erreur, donc elle n'a rien d'évident ni de systématique cette erreur.
    
    Il travaille sur des flottants de 64 bits.
    exemple :
    - 2⁴⁹ + 1 - 2⁴⁹ renvoi 1
    - 2⁵⁰ + 1 - 2⁵⁰ renvoi 0
    Donc il y a le même problème, à ceci près qu'il arrive plus tard.
    
    Les vrais naviguent en -42
  - [^] # Re: Rien de surprenant
    
    Posté par Marco le 18 décembre 2017 à 13:40. Évalué à 6. Dernière modification le 18 décembre 2017 à 13:41.
    
    En fait excel fait également l'erreur mais quand il voit que c'est très proche de 0 il affiche 0 (depuis 97).
    https://support.microsoft.com/fr-fr/help/78113/floating-point-arithmetic-may-give-inaccurate-results-in-excel
    - [^] # Re: Rien de surprenant
      
      Posté par arnaudus le 18 décembre 2017 à 16:40. Évalué à 3.
      
      Ça n'est pas une solution très élégante. Si tu fais 1e-17 + 1e-17 et qu'on te renvoie 0, c'est quand même étrange, non?
      - [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 18 décembre 2017 à 22:41. Évalué à -2.
        
        Entièrement d'accord, c'est tout aussi faux.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
  - [^] # Re: Rien de surprenant
    
    Posté par rewind (Mastodon) le 18 décembre 2017 à 13:43. Évalué à 2.
    
    Faut reconnaitre que sur un exemple comme ça, ça fait tout de même tâche. Ce serait pas mal d'activer une bibliothèque en précision infinie par défaut. Ensuite, si tu fais un soft qui demande bcp de calculs, à toi de passer en flottant "natif", mais quand il s'agit d'additionner ou de soustraire des valeurs "simples", c'est dommage de tomber sur ça.
    
    Erreur de raisonnement. Ce qui te paraît «simple» ne l'est pas pour l'ordinateur et inversement. Un ordinateur, il calcule en faisant une erreur mais en fait, on s'en fout dans 95% des cas. Par exemple, pour les calculs 3D dans les jeux, tous les calculs se font en flottants 32 bits et même avec toutes ces erreurs horribles, ça suffit. Bon, parfois, ça peut donner quelques glitchs mais dans l'ensemble, rien ne justifie de passer à 64 bits pour avoir plus de précision.
    - [^] # Re: Rien de surprenant
      
      Posté par Boa Treize (site web personnel) le 18 décembre 2017 à 17:39. Évalué à 7. Dernière modification le 18 décembre 2017 à 17:41.
      
      Il y a aussi comme célèbre exemple la racine carrée inverse rapide de Quake III qui fait un calcul très approximatif (mais suffisamment précis pour les besoin du jeu) avec un algorithme d'une simplicité et d'une vitesse ahurissantes, au prix d'une incompréhension totale pour un non-initié.
      
      Approximation de 1 divisé par la racine carrée de i : un décalage de bits et une soustraction d'un nombre magique. Dans le code source : 0x5f3759df - ( i >> 1 );
      
      Inévitable exclamation d'incrédulité de tout programmeur habitué aux nombres à virgule flottante. Voir l'article pour le détail et l'explication détaillée.
  - [^] # Re: Rien de surprenant
    
    Posté par Yth (Mastodon) le 19 décembre 2017 à 08:44. Évalué à 3.
    
    Excel t'affiche une valeur approchée à 10-x près, avec x<17.
    
    De rien.
    
    Yth.
  - [^] # Re: Rien de surprenant
    
    Posté par Nicolas Boulay (site web personnel) le 20 décembre 2017 à 11:20. Évalué à 3.
    
    Excel faisait (fait ?) encore pire. Il passe par une représentation décimal avec sérialisation/dématérialisation qui peut massacrer un résultat.
    
    "La première sécurité est la liberté"
  - [^] # Mot
    
    Posté par Arthur Accroc le 23 décembre 2017 à 13:31. Évalué à 5.
    
    Faut reconnaitre que sur un exemple comme ça, ça fait tout de même tâche.
    
    Plutôt « tache », en tout cas.
    Ce n’est pas le même mot, leur signification est différente et ils ne se prononcent pas pareil en français (en parisien, je ne sais pas — « côte » et « cote » ne se prononcent pas pareil non plus, en français).
    
    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
- [^] # Re: Rien de surprenant
  
  Posté par 🚲 Tanguy Ortolo (site web personnel) le 18 décembre 2017 à 12:40. Évalué à 9.
  
  Tu découvres simplement que les nombres décimaux non entiers ne sont pas représentables nativement par un ordinateur de manière exact. Pour des raisons d'optimisation, la quasi-totalité des langages de programmation (qui se basent sur le comportement du processeur) utilisent une représentation de ces nombres comme flottant qui n'ont pas une précision infinie.
  
  Ça ne suffit pas à expliquer l'erreur, parce qu'en décimal, 2, 1,8 et 0,2 sont représentables sans erreur. La source du problème, c'est que les nombres sont représentés en binaire à virgule flottante. Ainsi, 0,5 sera représenté comme 0,1 en base 2, sans erreur. En revanche, 1,8 et 0,2 ne sont pas représentables sans erreur en base 2, leur développement après la virgule étant infini.
  - [^] # Re: Rien de surprenant
    
    Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 18 décembre 2017 à 14:01. Évalué à 3.
    
    La règle pour savoir si un nombre y est représentable de manière décimale en base x = pqr… (où p, q, r… sont les diviseurs de x) est :
    
    Il existe k,l,n,m… entiers tels que y = k/(p^l qⁿ r^m…)
    
    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
- [^] # Re: Rien de surprenant
  
  Posté par snowball (site web personnel) le 18 décembre 2017 à 15:12. Évalué à 6.
  
  Tu découvres simplement que les nombres décimaux non entiers ne sont pas représentables nativement par un ordinateur de manière exact.
  
  Ce n'est pas tout à fait vrai. Je me place, pour simplifier les écritures, dans le cas où on travaille sur un processeur 64 bits. La norme de représentation IEEE754 stipule que les "rationnels binaires" sont exactement représentables en machine. Il s'agit des rationnels de la forme $k2^{-52}$ où $k\in\left\{0,\dots,2^{52}-1\right\}$ ( désigne ce qu'on appelle la mantisse du nombre). Je ne mentionne pas la partie "exposant" du flottant qui permet essentiellement d'atteindre des rationnels de la forme précédente multipliés par des puissances positives ou négatives de 2 (histoire de se "rapprocher" de 0 ou de $+\infty$ ) et je ne parle pas du bit de signe non plus (qui permet d'aller titiller les négatifs).
  
  Les calculs qui sont faits avec ces rationnels binaires sont parfaitement exacts tant que les tailles des résultats restent dans les plages de représentation imposées par la norme.
  
  Tout rationnel binaire est un décimal mais la réciproque est fausse.
  
  En gros un nombre de la forme 0,375 (qui vaut 1/8, c'est à dire $3\times 2^{49}\times 2^{-52}$ ) est un rationnel binaire, donc est représentable sur 64 bits sans aucune approximation. En mémoire, les 52 derniers bits de mantisse (occupant 6,5 octets) seraient
  110000000000000000000000000000000000000000000000000000
  Pour illustrer, en python, si tu calcules: 0.25 - 0.375 + 0.125 alors il sort bien 0.0.
  
  A contrario, un nombre comme 0,2 (qui vaut 1/5) ne l'est pas (car c'est un décimal non rationnel binaire). Il sera stocké avec une mantisse de la forme $k2^{-52}$ avec arrondi (en fonction des options données au FPU) à l'entier le plus près, ou inférieur, ou supérieur.
  
  C, C++, Pascal, Ada, Python ou autres utilisent la norme IEEE754 pour manipuler des flottants et font tous une approximation au rationnel binaire le plus proche avant de procéder aux opérations. On peut utiliser des librairies qui augmentent le nombre de chiffres de la mantisse et donnent l'illusion d'une précision infinie, ce qui est évidemment totalement faux. Par exemple, même avec des bibliothèques spécialisées comme GMP pour faire de l'arithmétique multiprécision, la valeur de l'entier $10^{10^{90}}$ n'est pas représentable en machine (car le nombre de chiffres à afficher (à savoir $1+ 10^{90}$ ) dépasse le nombre d'atomes dans l'univers visibles !!!).
  - [^] # Re: Rien de surprenant
    
    Posté par Aldoo le 18 décembre 2017 à 17:05. Évalué à 3.
    
    On peut utiliser des librairies qui augmentent le nombre de chiffres de la mantisse et donnent l'illusion d'une précision infinie, ce qui est évidemment totalement faux.
    
    Certes. Mais il n'y a pas que les représentations en virgule flottante dans la vie.
    
    Avec d'autres représentations, il est tout à fait possible de réaliser des calculs exacts avec n'importe quels nombres rationnels (limités seulement par la mémoire de la machine). En effet, dans toute base, un rationnel admet une représentation finitaire, par exemple :
    - sous la forme d'une fraction d'entiers,
    - ou bien sous la forme d'un début de développement et d'une période (séquence de chiffres qui se répète à l'infini).
    
    Dans les deux représentations, on peut implémenter les opérations usuelles. C'est moins efficace que des flottants (même des "gros" flottants), mais absolument pas impossible.
    
    la valeur de l'entier 10^10⁹⁰ n'est pas représentable en machine
    
    Pour pinailler, c'est faux aussi : nous venons tous deux de le faire (ok, je botte en touche : une séquence aléatoire qui aurait autant de chiffres, elle, ne serait pas représentable).
    - [^] # Re: Rien de surprenant
      
      Posté par gUI (Mastodon) le 18 décembre 2017 à 20:34. Évalué à -5.
      
      Mais il n'y a pas que les représentations en virgule flottante dans la vie.
      
      Mais merci !!!!
      
      A croire que tout le monde trouve acceptable que un ordinateur soit incapable d'effectuer correctement "2.0 - 1.8 - 0.2". Putain de merde, mais c'est un bug et rien d'autre ! Et c'est pas parce qu'on a l'explication (que je comprends parfaitement, inutile de m'expliquer, j'ai appris ça à l'école) que ça n'en est pas un.
      
      On est parti là-dessus en 1985 (ou un peu avant sûrement) parce que c'était la bonne idée du moment, et maintenant personne pour remettre ça en question. Ouvrez un peu vos Chakras, regardez les choses en face, des milliards de transistors pour au final ne pas être capable de faire une soustraction de CM1 !
      
      Je pense qu'il y a mieux à faire.
      
      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
      - [^] # Re: Rien de surprenant
        
        Posté par Dr BG le 18 décembre 2017 à 21:09. Évalué à 5. Dernière modification le 18 décembre 2017 à 21:12.
        
        Je pense qu'il y a mieux à faire
        
        Je t'en prie, fais-le et devient le nouveau Bill Gates (pour ce qui est de la fortune).
        
        Sinon, comme tu as pu le lire dans d'autre commentaires, bien-sûr que ça se fait, mais seulement quand on en a besoin (rarement) parce que c'est coûteux.
        
        [^] # Re: Rien de surprenant
        
        Posté par gUI (Mastodon) le 18 décembre 2017 à 22:34. Évalué à -2.
        
        (Dur de se faire comprendre en se prenant des "inutiles" à chaque mot)
        
        Coûteux en quoi ? Il fait 3 soustractions, ça a pris qques microsecondes, si un calcul vrai met 10x plus de temps ça coûte à qui ? Justement à ceux qui savent tout ça et qui peuvent dire "c'est trop complexe, je passe en floating".
        
        99,999% du temps on fait des trucs pas pressés donc le temps importe peu. Pourquoi accepter fatalement cette erreur de calcul (parce que ça en est une ?).
        
        Non mais j'essaie juste de réfléchir différemment c'est tout.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Rien de surprenant
        
        Posté par Dr BG le 18 décembre 2017 à 22:56. Évalué à 6. Dernière modification le 18 décembre 2017 à 22:57.
        
        Non, ce n'est pas une erreur de calcul. Le résultat est exactement celui attendu dans le cadre d'un calcul en flottants. Si tu veux un autre type de représentation des nombres, eh bien tu les utilises !
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 18 décembre 2017 à 23:21. Évalué à 6.
        
        @gUI
        
        En fait, on peut démontrer qu'il n'existe aucun système informatique de calcul basé sur nos machines classiques permettant de faire des calculs justes avec les nombres réels (déjà parce qu'ils ne sont pas représentables en machine, pour des raisons mathématiques liées à la nature des nombres réels).
        Ce n'est pas une question de progrès. Je dirais même qu'on a suffisamment fait de progrès en science pour démontrer que ce que tu voudrais n'existe pas.
        
        Excel ou d'autres tentent de gommer les merdouilles qu'ils calculent mal par des algos plus ou moins sophistiquées (des magouilles en fait), pour donner un résultat tout rond (parce que c'est censé être probablement tout rond mais bon, c'est pas certain), ça les regarde. Ca ne rend pas les résultats qu'ils donnent plus crédibles en général.
        
        [^] # Re: Rien de surprenant
        
        Posté par Marco le 19 décembre 2017 à 10:18. Évalué à 3.
        
        99,999% du temps on fait des trucs pas pressés donc le temps importe peu. Pourquoi accepter fatalement cette erreur de calcul (parce que ça en est une ?).
        
        Parce que 99% du temps on s'en fout de l'erreur d'arrondi la question est pourquoi on s'en fout ?
        Parce que l'erreur d'arrondi est négligeable par rapport à l'erreur que tu as déjà pris à cause de ton capteur.
        Si par exemple tu mesures une température, tu as une sonde relié à ton ordinateur, ta sonde peut mesurer 23,1°C alors qu'en réalité il fait 22.6°C. Au final l'arrondi de ton ordinateur est très négligeable par rapport aux erreurs qu'on a déjà faites.
        
        Sur toutes les mesures tu as une erreur avant même celle de l'arrondi. Tu as déjà essayé de te peser deux fois de suite sur ta balance et obtenir un poids différents ? Ce n'est pas l'erreur d'arrondi qui te fait passer de X,1 à X,3.
        Sur les instruments de tous les jours les erreurs peuvent aller jusqu'à 10%, après évidemment dans l'industrie en fonction des besoins on peut descendre en dessous, bref tout ca pour dire que pour tout ce qui est du domaine de la mesure, le fait d'avoir une erreur de 10^-15 c'est le cadet de nos soucis
        
        [^] # Re: Rien de surprenant
        
        Posté par Boa Treize (site web personnel) le 19 décembre 2017 à 10:36. Évalué à 2.
        
        Tu as déjà essayé de te peser deux fois de suite sur ta balance et obtenir un poids différents ? Ce n'est pas l'erreur d'arrondi qui te fait passer de X,1 à X,3.
        
        Toi tu as une bonne balance.
        
        Car il y a sur le marché (y compris dans les grandes marques) de plus en plus de balance qui ont des variations de mesure de l'ordre de 0,5 kg voire pire, mais qui le masquent avec un algorithme « si la nouvelle mesure est proche de l'ancienne, j'affiche l'ancienne ».
    - [^] # Re: Rien de surprenant
      
      Posté par snowball (site web personnel) le 18 décembre 2017 à 22:02. Évalué à 5.
      
      Certes. Mais il n'y a pas que les représentations en virgule flottante dans la vie.
      
      Le sujet de la conversation c'est la représentation des flottants en machine et les problèmes que ça pose pour faire des calculs du quotidien. C'est de ça que je parlais aussi.
      
      Avec d'autres représentations, il est tout à fait possible de réaliser des calculs exacts avec n'importe quels nombres rationnels (limités seulement par la mémoire de la machine)
      
      Si tu veux pinailler, pinaillons. Ca fait très, très, très peu d'entiers "ceux dont l'écriture est limitée par la mémoire de la machine" puisque c'est fini de chez fini ! C'est peanuts :)
      
      La promesse de l'infini est une illusion totale et ce n'est d'ailleurs absolument pas celle tenue par les logiciels de calcul formel munis de librairies d'arithmétique multiprécision.
      
      En arithmétique, ces bibliothèques fournissent tout au mieux des outils pour conjecturer, rien de plus.
      
      En première année, toujours en arithmétique, les étudiants font souvent cet exercice qui consiste à déterminer le dernier chiffre de $2017^{2017^{2017}}$ . Le premier truc qu'on leur dit, c'est "abandonnez l'idée d'effectuer directement ce calcul avec un ordinateur, et on leur demande d'expliquer pourquoi".
      
      Idem pour la valeur de l'entier $10^{10^{90}}$ , qui contrairement à celle de 123 n'est pas représentable en machine au sens de la représentation des entiers en machine (c'est à dire via l'écriture dans une base). Par exemple si tu demandes à un système de calcul formel de de te calculer la somme de ses chiffres, il ne pourra pas (alors que ça fait juste 1) car il ne peut le calculer au sens de la représentation dans une base.
      - [^] # Re: Rien de surprenant
        
        Posté par Aldoo le 19 décembre 2017 à 10:33. Évalué à 2.
        
        Si tu veux pinailler, pinaillons. Ca fait très, très, très peu d'entiers "ceux dont l'écriture est limitée par la mémoire de la machine" puisque c'est fini de chez fini ! C'est peanuts :)
        
        C'est peanuts, mais ça inclut les nombres qu'un utilisateur humain entre dans une calculatrice (= rationnels décimaux avec nombre de chiffres à taille "humaine").
        Pouvoir faire des calculs exacts sur cet ensemble-là est un besoin récurrent.
        
        Ainsi, pour te paraphraser, on est dans le sujet du journal.
        
        La promesse de l'infini est une illusion totale et ce n'est d'ailleurs absolument pas celle tenue par les logiciels de calcul formel munis de librairies d'arithmétique multiprécision.
        
        Loin de moi l'idée de promettre l'infini.
        
        Il est en revanche possible de promettre de ne pas retourner de résultat faux ou imprécis, pour peu qu'on s'autorise à retourner "je ne sais pas", quand on sort (ou risque de sortir) des capacités de la machine pour la représentation utilisée.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 12:44. Évalué à 5.
        
        C'est peanuts, mais ça inclut les nombres qu'un utilisateur humain entre dans une calculatrice
        
        2017 rentre dans une calculatrice, $2017^{2017}$ aussi, mais le résultat te donne une erreur.
        On parlait bien de calculateur formel ? (tu embrayes sur la calculatrice là).
        La calculatrice fait les mêmes erreurs que python (sauf qu'elle utilise la représentation BCD pour éviter de surprendre l'utilisateur quand il manipule des décimaux). Dès qu'on la fait calculer avec des 1/3, paf !, elle fait les mêmes "bêtises" que Python.
        
        Si on reparle de calculateur formel, celui qui l'utilise aujourd'hui est un utilisateur d'un type spécial: il sait que son calculateur ne peut faire que très peu de choses et il doit malgré tout sortir des choses cohérentes. Ca nécessite des connaissances (souvent importantes), pour arriver à faire des choses intéressantes malgré tout.
        
        Il est en revanche possible de promettre de ne pas retourner de résultat faux ou imprécis, pour peu qu'on s'autorise à retourner "je ne sais pas", quand on sort (ou risque de sortir) des capacités de la machine pour la représentation utilisée.
        
        Ce n'est malheureusement pas du tout le cas (sauf à faire des petits calculs tout gentils). Mais, par exemple: tu demandes à Maple ou Mathematica (ou ce que tu veux) de calculer la somme des $\cos\left(n^2\right)$ pour n variant de 1 à 10000000 (par exemple pour conjecturer si la série est bornée). Tous les nombres en jeu sont gentils (pas trop gros) et pourtant, si tu fais l'expérience, en lui demandant 2 chiffres après la virgule de précision, elle va te renvoyer un truc du genre 32.45, puis tu lui en demandes le même calcul avec 3 chiffres de précision et elle peut te renvoyer un truc du genre -1234.769 (fais l'expérience).
        Pourtant les nombres manipulés sont petits, pourtant tu as demandé d'augmenter la précision (chaque fois que tu vas demander d'augmenter la précision tu obtiendras des résultats totalement farfelus qui semblent contradictoires).
        
        Donc, non, un calculateur formel, ne permet que dans des cas simples, des "cas d'école", de donner des résultats satisfaisants mais la plupart du temps, dès qu'on en a justement carrément besoin, ça calcule comme ça peut, c'est à dire très mal. Et c'est normal car:
        
        Aucun système de calcul basé sur les machines actuelles ne peut prétendre ne serait-ce que de manipuler correctement les réels de [0;1].
        Ce n'est pas parce qu'on est mauvais, mais parce qu'on est assez bon pour démontrer que c'est impossible.
        
        Bon après, si on touche aux ordinateurs quantiques, ça change tout hein (même s'il n'y aura toujours pas de miracle). Mais là je parle des machines classiques.
        
        [^] # Re: Rien de surprenant
        
        Posté par Aldoo le 19 décembre 2017 à 16:01. Évalué à 3.
        
        2017 rentre dans une calculatrice, 2017²⁰¹⁷ aussi,
        
        Attention 2017^2017, c'est déjà une opération.
        
        mais le résultat te donne une erreur.
        
        C'est un bon comportement pour une calculatrice de base, ça rejoint ce que je disais à la fin. Pour un logiciel de calcul formel, on peut laisser 2017²⁰¹⁷ tel quel, en espérant qu'une simplification ait lieu plus tard, ce n'est pas pire que de laisser e^π tel quel.
        
        On parlait bien de calculateur formel ? (tu embrayes sur la calculatrice là).
        
        Je parlais juste des possibilités théoriques pour tout calcul effectué par un ordinateur concret. La calculatrice n'est qu'un cas particulier important.
        
        la somme des $\cos\left(n^2\right)$
        
        Ouhla, on parlait de nombres rationnels ! Cela dit, là encore, il est tout à fait possible de programmer le logiciel de telle sorte qu'il donne (une sur-approximation de) les marges d'erreur.
        
        Ce que je voulais dire, c'est qu'à défaut de promettre de réussir tous les calculs, il est possible d'avertir l'utilisateur qu'un résultat est (ou est susceptible d'être) aberrant. Dans les cas simples, l'utilisateur averti s'en doutait déjà, mais ça ne saute pas forcément tout le temps aux yeux (cf. calcul à virgule flottante dans les langages de programmation classiques).
        
        Aucun système de calcul basé sur les machines actuelles ne peut prétendre ne serait-ce que de manipuler correctement les réels de [0;1].
        
        Ce genre d'énoncé est bien trop flou. Pris tel quel, il est trivial (cf. fonctions non calculables). Pourtant, avec quelques aménagements, on peut avoir des systèmes de calcul corrects et utiles (p. ex. : restriction aux opérations continues calculables et résultats avec intervalles d'erreur).
        
        Bon de toute façon, on ne parlait pas de nombres réels.
        
        [^] # Re: Rien de surprenant
        
        Posté par snowball (site web personnel) le 19 décembre 2017 à 16:20. Évalué à 1.
        
        Attention 20172017, c'est déjà une opération.
        
        Tu peux l'écrire, ça devient une opération quand tu appuies sur exe. Attention j'ai écrit $2017^{2017}$ et non .
        
        Je parlais juste des possibilités théoriques pour tout calcul effectué par un ordinateur concret
        
        Ordinateur, calculatrice : même combat, mêmes problèmes, la seule chose qui change c'est la taille de la mantisse.
        
        Ouhla, on parlait de nombres rationnels ! Cela dit, là encore, il est tout à fait possible de programmer le logiciel de telle sorte qu'il donne (une sur-approximation de) les marges d'erreur
        
        Non. Ce n'est pas possible. Ou alors dis moi comment on fait.
        
        Ce que je voulais dire, c'est qu'à défaut de promettre de réussir tous les calculs, il est possible d'avertir l'utilisateur qu'un résultat est (ou est susceptible d'être) aberrant.
        
        Non plus. Si tu donnes à Maple ou autre, à calculer la somme des $\cos (n^2)$ de 1 à 10000000 il va te donner un résultat sans te prévenir de rien. Si tu augmentes la précision
        souhaitée, il te donnera des résultats qui semblent contradictoires, jamais il ne te préviendra. Pourtant les nombres utilisés sont très petits (on tape pas plus haut 10 puissance 14).
        
        Ce genre d'énoncé est bien trop flou. Pris tel quel, il est trivial
        
        Prends le tel quel. Tant mieux s'il est trivial vu qu'il est vrai. Si tu veux que je précise le "flou" je dirais, par exemple qu'il ne peut même pas gérer les rationnels de [0;1] de la forme p/q avec p < q premiers entre eux et $q > 10^{10^{90}}$ .
        
        Bon de toute façon, on ne parlait pas de nombres réels.
        Ca tombe bien, je viens de t'expliquer pourquoi même les rationnels de [0;1] ne sont pas manipulables (seule une infime partie d'entre eux le sont).
        
        Si on utilise un calculateur formel pour faire des choses basiques même avec les entiers on est très vite limité. Par exemple, résoudre un problème de première année (ou de bon terminale S) du type "donner le dernier chiffre de $2017^{2017^{2017}}$ ".
        
        Encore une fois, que ce soit avec les entiers, les rationnels, ou les réels, un pc ne peut pas faire grand chose, heureusement, souvent, on peut s'en contenter.
        
        La seule chose qu'un pc sait faire, très vite et très bien, c'est le calcule modulaire modulo n où n est relativement petit (ie rentre en mémoire). Ca s'arrête là, et c'est déjà bien.
- [^] # Re: Rien de surprenant
  
  Posté par 2PetitsVerres le 18 décembre 2017 à 15:22. Évalué à 2. Dernière modification le 18 décembre 2017 à 15:25.
  
  Edit: le commentaire juste au dessus est bien mieux que le mien, et il m'a grillé :-)
  
  Tu découvres simplement que les nombres décimaux non entiers ne sont pas représentables nativement par un ordinateur de manière exact
  
  C'est effectivement l'idée globale du pourquoi, mais ce n'est pas une descriptions très correcte de la situation. Il existe des nombres non entiers représentables nativement de façon exacte (0,5 par exemple), tout comme il existe des nombres décimaux entiers qui ne sont pas représentables nativement (je n'ai pas envie d'en rechercher un, mais disons qu'à partir d'une certaine valeur assez grande, c'est le cas.)
  
  Après la partie importante c'est le nativement. Quand il faut plus de précision (c'est plutôt rare, en fait, sauf les cas où on veut faire de la virgule fixe, mais c'est différent) il est possible d'avoir besoin recours à des logiciels ou bibliothèques spécialisées dans la précision arbitraire.
  
  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Exposant.

Posté par Seb le 18 décembre 2017 à 11:18. Évalué à 7.

Ca vaut ce que ça vaut, mais de mon côté l'exposant est -17, pas -1.
Une erreur à la 17ème décimale a peu de chance de m'impacter un jour dans mes usages de python :)
Il me semble avoir lu pas mal de choses dernièrement ici sur les méthodologies de calcul exact en virgule flottante (ou fixe d'ailleurs).
- [^] # Re: Exposant.
  
  Posté par snowball (site web personnel) le 18 décembre 2017 à 16:17. Évalué à 10.
  Je serais beaucoup plus prudent que toi :)
  Exemple en python 3:
```
r=0
while r != 1:
  r += 0.1
print ('fini !')
```
  Ça boucle à l'infini sans jamais afficher 'fini !' alors que "normalement", ça devrait s'arrêter au bout de 10 tours.
  Le pire c'est que si tu contrôles avec des print (r), tu verras qu'il "passe" par 1 (à l'affichage mais pas en interne !!!)
  Ce genre d'erreurs c'est ultra fréquent et on peut s'arracher les cheveux dessus pendant longtemps avant de se rendre compte qu'on doit apprendre des choses sur la représentation des flottants en machine.
  - [^] # Re: Exposant.
    
    Posté par Seb le 19 décembre 2017 à 09:34. Évalué à 3.
    
    avant de se rendre compte qu'on doit apprendre des choses sur la représentation des flottants en machine.
    
    Ben voilà, CQFD :)
    Merci pour l'exemple !
  - [^] # Utilisation des flottants
    
    Posté par Arthur Accroc le 20 décembre 2017 à 05:57. Évalué à 5.
    r=0 while r != 1: r += 0.1 print ('fini !')
    Une règle de base de mes lointains débuts en informatique : ne jamais utiliser d’égalité (ou juste de différence, qui revient au même) comme règle d’arrêt, toujours utiliser une infériorité ou une supériorité.
```
r=0
while r < 1:
  r += 0.1
print ('fini !')
```
    Ça te garantit que ta boucle s’arrête.
    Ça ne te garantit pas qu’elle s’arrête au tour attendu.
    
    En l’occurrence :
```
print(r)
1.0999999999999999
```
    Conclusion personnelle : un programme qui utilise des flottants dans sa logique de contrôle et pas uniquement pour représenter des données a de forts risques d’être bogué (je ne dis pas que c’est toujours le cas, mais il faut vraiment savoir ce qu’on fait).
    
    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
    - [^] # Re: Utilisation des flottants
      
      Posté par snowball (site web personnel) le 20 décembre 2017 à 07:26. Évalué à 6.
      
      Sans blague !
      Pourquoi penses-tu que j'ai écrit cet exemple ? Pour montrer que les tests d'égalité sur les flottants étaient intelligents ou bien pour montrer que même en utilisant des "décimaux" tout gentils en apparence on peut avoir de graves surprises si l'on méconnaît l'arithmétique flottante ?
# Étrange

Posté par gromitb le 18 décembre 2017 à 11:25. Évalué à 7.
Chez moi, c'est plutôt :
```
$ python3
Python 3.4.3 (default, Nov 28 2017, 16:41:13) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2 -1.8 - 0.2
-5.551115123125783e-17
```
Du coup je pense à un copier/coller oublieux, et ça me rassure un peu (parce que sur le coup, en voyant le « …e-1 » à la place de « …e-17 », j'ai manqué taper « formation berger » dans Duckduckgo avant de balancer tout le bouzin par la fenêtre …)

Mais ça ne change rien au fond…
# Puisqu'on est dans le sujet…

Posté par SpaceFox (site web personnel, Mastodon) le 18 décembre 2017 à 11:38. Évalué à 7.
Deux ressources pour aller plus loin que la simple explication du phénomène :
- Un effet de bord moins connu : changer l'ordre des terme d'une somme peut changer le résultat.
- Plus velu : comment contrôler la propagation des erreurs de calcul numérique ← où l'on voit entre autres que dans certains cas, le calcul peut très vite diverger de la théorie !
La connaissance libre : https://zestedesavoir.com
- [^] # Re: Puisqu'on est dans le sujet…
  
  Posté par Joalland le 18 décembre 2017 à 11:51. Évalué à 4.
  
  Et ce vieux papier, qui traite de la stabilité de la résolution des systèmes linéaires.
- [^] # Re: Puisqu'on est dans le sujet…
  
  Posté par rewind (Mastodon) le 18 décembre 2017 à 13:33. Évalué à 4.
  
  What Every Computer Scientist Should Know About Floating-Point Arithmetic (pdf)
  
  Why don’t my numbers add up?: très bon site qui dit notamment comment comparer de manière raisonnable deux flottants (oui, == sur des flottants, ça ne marche pas).
  - [^] # Re: Puisqu'on est dans le sujet…
    
    Posté par dcp le 21 décembre 2017 à 10:03. Évalué à 0.
    
    What Every Computer Scientist Should Know About Floating-Point Arithmetic (pdf)
    
    Merci rewind ! Surpris que personne n'ait sorti cette référence plus tôt.
# Et ça c’est rien, 2+2= …

Posté par Thomas Douillard le 18 décembre 2017 à 12:02. Évalué à 8.

https://codegolf.stackexchange.com/questions/28786/write-a-program-that-makes-2-2-5

Mais bon, c’est de la programmation, un truc de gros dégueux qui manque de pureté. Et du côté des maths ? ben c’est pas forcément plus simple : http://www2.kenyon.edu/Depts/Math/Milnikel/boolos-godel.pdf
# Y a qu'à utiliser un bon langage

Posté par Framasky (site web personnel) le 18 décembre 2017 à 12:18. Évalué à 10.
```
% perl6
To exit type 'exit' or '^D'
> 2 - 1.8 - 0.2
0
```
De rien.

Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
- [^] # Re: Y a qu'à utiliser un bon langage
  
  Posté par barmic le 18 décembre 2017 à 12:32. Évalué à 4.
  
  perl6 ? Ça existe pour de vrai ?
- [^] # Re: Y a qu'à utiliser un bon langage
  
  Posté par David Marec le 18 décembre 2017 à 13:29. Évalué à 1. Dernière modification le 18 décembre 2017 à 13:31.
```
Python 2.7.12 (default, Nov 20 2017, 18:23:56) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 2- (1.8 +0.2)
0.0
```
  ou
```
$ bc -l 
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
2 - 1.8 -0.2
0
```
  Serviteur.
  - [^] # Re: Y a qu'à utiliser un bon langage
    
    Posté par _kaos_ le 18 décembre 2017 à 13:54. Évalué à 1.
    Démonstration rapide pour le second exemple…
```
bc -l
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'. 
1/3+1/3+1/3
.99999999999999999999
```
    Matricule 23415
    - [^] # Re: Y a qu'à utiliser un bon langage
      
      Posté par David Marec le 18 décembre 2017 à 13:58. Évalué à -1.
      
      C'est tricher.
      1/3 ne peut pas être représenté par un nombre fini de chiffres.
      
      Contrairement à 1.8 et 0.2 .
      - [^] # Re: Y a qu'à utiliser un bon langage
        
        Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) le 18 décembre 2017 à 14:07. Évalué à 6.
        
        En base 3 et en français un tiers s'écrit 0,1. Non ? Peut-on considérer que 1 soit un nombre fini ? ou qu'il ait encore de l'avenir ? Cette question est laissé à l'appréciation du lecteur :-).
        
        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
      - [^] # Re: Y a qu'à utiliser un bon langage
        
        Posté par Renault (site web personnel) le 18 décembre 2017 à 14:15. Évalué à 4.
        
        En réalité 0.9999999 (avec des 9 à l'infini) et 1 sont la même valeur d'un point de vue mathématique. C'est juste deux manière de l'exprimer.
        
        Donc 1/3 * 3 = 0.9999999 (avec des 9 à l'infini) c'est exact.
    - [^] # Re: Y a qu'à utiliser un bon langage
      
      Posté par David Marec le 18 décembre 2017 à 14:05. Évalué à 6.
      Comme l'aurait dit M. Cyclopède:
      
      bc 1.06.95 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1/3 *3 .99999999999999999999 3* 1/3 1.00000000000000000000
      
      «étonnant, non ?»
      - [^] # Non.
        
        Posté par Thomas Douillard le 18 décembre 2017 à 14:17. Évalué à 5.
        
        ABSOLUTELY NO WARRANTY
- [^] # Re: Y a qu'à utiliser un bon langage
  
  Posté par Piervit le 18 décembre 2017 à 19:09. Évalué à 2. Dernière modification le 18 décembre 2017 à 19:09.
  
  Je ne comprend pas bien en quoi c'est un bon langage.
  Est ce qu'il se permet de faire l'arrondi sur le résultat (et donc la perte de précision)?
  
  Le résultat dans un langage correct:
  
  OCaml version 4.05.0
  # 2 - 1.8 - 0.2;;
  Error: This expression has type float but an expression was expected of type
  int
  - [^] # Re: Y a qu'à utiliser un bon langage
    
    Posté par anaseto le 18 décembre 2017 à 20:42. Évalué à 2.
    
    Si mes souvenirs sont bons (je ne suis Perl 6 que de loin), Perl 6 considère que c'est des nombres rationnels et fait le calcul exact avec des fractions. Pour faire des calculs de flottants classiques (et donc performants), il faut lui dire explicitement, il me semble.
# Calculatrice Numworks

Posté par bobo38 le 18 décembre 2017 à 14:15. Évalué à 3.

Il y a eu un article similaire sur NextInpact:
https://www.nextinpact.com/news/105788-calculatrice-numworks-calcul-exact-scripts-python-et-autres-nouveautes-avec-firmware-1-2-0.htm

une calculatrice libre basée sur Python dont un des problèmes était celui que tu pointes précisément
# C'est bien une erreur de la part de l'utilisateur !

Posté par THE_ALF_ le 18 décembre 2017 à 15:04. Évalué à 9.
Comme dit au-dessus, c'est bien une erreur de l'utilisateur de s'attendre à obtenir strictement 0 au lieu de la valeur en 1e-17. Si on veut faire des calculs exacts en écriture décimale, il faut utiliser… le module decimal:
```
>>> from decimal import Decimal
>>> Decimal("2")-Decimal("1.8")-Decimal("0.2")
Decimal('0.0')
```
- [^] # Re: C'est bien une erreur de la part de l'utilisateur !
  
  Posté par karteum59 le 18 décembre 2017 à 15:23. Évalué à 3.
  
  Et en Julia tu peux simplement taper 2 - 18//10 - 2//10 pour utiliser le type "nombre rationnels" (représenté comme un couple d'entiers) plutôt qu'un float ;)
  - [^] # Re: C'est bien une erreur de la part de l'utilisateur !
    
    Posté par foobarbazz le 18 décembre 2017 à 19:11. Évalué à 2.
    Dans un langage comme Haskell :
```
Prelude> 2 - 1.8 - 0.2 :: Rational
0 % 1
Prelude> 2 - 1.8 - 0.2 
-5.551115123125783e-17
```
    Le type de 0.0 est Fractional t => t.
    C'est à dire que les constantes numériques sont polymorphes. Par défaut dans l’interpréteur c'est une instance de Double qui est utilisée. Mais on peut forcer l'utilisation d'une autre instance avec une annotation de type.
    
    Petit commentaire 1 : Il faut arrêter de considérer que les float et les double sont une implémentation des nombres réels. C'est faux. Les float et les doubles n'ont littéralement aucune propriété algébrique. Vraiment aucune. Ce n'est même pas un magma (le niveau 0 de la structure algébrique).
    
    Petit commentaire 2 : Les nombres réels, ce sont à peu près les seuls qui n'existent pas dans la nature. Quel que soit la raison pour laquelle vous pensez devoir les utiliser, il y a fort à parier que vous avez tort. Les seuls cas d'usage légitime c'est quand on a besoin de grosses performances, et qu'on veille à éviter les opérations vraiment déconnantes.
    - [^] # Re: C'est bien une erreur de la part de l'utilisateur !
      
      Posté par 2PetitsVerres le 18 décembre 2017 à 21:36. Évalué à 3.
      
      Les nombres réels, ce sont à peu près les seuls qui n'existent pas dans la nature
      
      La quadrature du ~~net~~ cercle aimerait avoir une discussion avec toi. Enfin, est-ce qu'un cercle parfait existe dans la nature ? Bonne question. Sinon je suis d'accord avec toi, sur l'usage, c'est rare d'en avoir besoin.
      
      Pour illustrer ça, on peut aussi dire que dans un système réel qui aurait une (ou des) interfaces hardware/software, on a en général un/des capteurs qui s'interfacent avec le logiciel au travers d'un convertisseur analogique/numérique qui a souvent 12/16 voire peut-être 24 bits, donc en utilisant un flottant sur 32 bits (avec 23+1 bits de mantisse) ou surtout des doubles sur 64 bits (dont 52+1 de mantisse), on est en général bien au delà de ce qu'on peut mesurer. Après il y a effectivement une propagation d'erreur, mais en partant de 24 bits mesurés et avec 53 de mantisse, il y a de la marge (bon, il faut faire attention à ce qu'on fait, mais en général, ça ne pose pas de problèmes. Faut toujours tester son code, et y réfléchir un peu, mais bon, rien d'impossible en général)
      
      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
      - [^] # Re: C'est bien une erreur de la part de l'utilisateur !
        
        Posté par foobarbazz le 19 décembre 2017 à 01:24. Évalué à 3. Dernière modification le 19 décembre 2017 à 01:29.
        
        La quadrature du net cercle aimerait avoir une discussion avec toi. Enfin, est-ce qu'un cercle parfait existe dans la nature ? Bonne question. Sinon je suis d'accord avec toi, sur l'usage, c'est rare d'en avoir besoin.
        
        Avec la matière que nous connaissons, non, ça n'existe pas.
        Ajout : pour développer, oui, on peut faire des constructions mathématique qui utilisent des nombres réels, ça ce comporte bien et tout, ça a plein de propriétés cool. Mais il y a fort à parier que l'espace et le temps soient discrets, et donc que les nombres réels n'existent pas.
        
        [^] # Re: C'est bien une erreur de la part de l'utilisateur !
        
        Posté par gUI (Mastodon) le 19 décembre 2017 à 23:14. Évalué à -2.
        
        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.
    - [^] # Re: C'est bien une erreur de la part de l'utilisateur !
      
      Posté par snowball (site web personnel) le 19 décembre 2017 à 07:39. Évalué à 3.
      
      Petit commentaire 2 : Les nombres réels, ce sont à peu près les seuls qui n'existent pas dans la nature.
      
      En 400avJC on ne disposait que des rationnels et l'absence des réels ne permettait pas de résoudre des problèmes issus de la géométrie naturelle, du genre:
      Comment tu fais pour calculer la diagonale d'un carré de de côté 1 sans les réels ?
      La diagonale d'un carré de côté 1 "n'existe pas dans la nature" ? (<-- je ne comprends pas vraiment ce que ça veut dire)
      
      2000 ans après, on résout les problèmes qu'on avait en construisant les réels (qui de fait existent dans nos têtes donc dans la nature).
# Puis-je me permettre de tester avec d'autres langages / vm

Posté par Christie Poutrelle (site web personnel) le 18 décembre 2017 à 15:29. Évalué à 4. Dernière modification le 18 décembre 2017 à 15:30.
```
[pounard@guinevere] /home/pounard
>  cat test.c 
#include <stdio.h>
```    int main () {
        printf("%.100f", 2 - 1.8 - 0.2);
        return 0;
    }
```
[pounard@guinevere] /home/pounard

gcc ./test.c
[pounard@guinevere] /home/pounard > ./a.out -0.0000000000000000555111512312578270211815834045410156250000000000000000000000000000000000000000000000[pounard@guinevere] /var/www/laborange/remote-current-3.x > php -a Interactive shell
php > echo 2 - 1.8 - 0.2;
-5.5511151231258E-17
php > ^C
``` [pounard@guinevere] /home/pounard
> node
> 2 - 1.8 - 0.2
-5.551115123125783e-17
> [pounard@guinevere] /home/pounard
>
# Autre réalité

Posté par Zenitram (site web personnel) le 18 décembre 2017 à 16:24. Évalué à 4.

Et bien je serais sûrement pêcheur en Martinique à l'heure actuelle :-D

Bon, en plus de la réalité indiqué (les flottants en informatique, un classique comme erreur humaine), j'ai autre chose à proposer, en langage non informatique, juste des maths et les indications d'arrondis.

2 - 1.8 - 0.2

Tu n'as pas dit 2.0, tu as dit 2. Le nombre après la virgule a son importance.
Donc (en schématisant) tu viens de dire :
tout nombre entre 1.500… et 2.499… minus tout nombre entre entre 1.7500… et 1.8499… minus tout nombre entre 0.1500… et 0.2499…
Ce qui fait que tout nombre entre 1.500… - 1.8499… - 0.2499… 2.499 - 1.7500 - 0.1500 et donc entre -0.599… et +0.599… est correct (dans la marge d'erreur que tu as indiqué)

OK --> []

PS : en fait, ça me fait penser aux gens qui disent que les sondages se sont plantés car le "49%" a gagné face au "51%", avec 50.5%, lors d'une élection, en oubliant de lire la marge d'erreur de 2% (donc en vrai, le sondage ne s'est pas planté contrairement à ce que pas mal de monde pense, 50.5% étant dans la marge d'erreur).
- [^] # Re: Autre réalité
  
  Posté par Renault (site web personnel) le 18 décembre 2017 à 16:31. Évalué à 4.
  
  OK --> []
  
  Tu n'as pas à sortir, c'est vrai. Les nombres significatifs sont importants. On ne peut pas créer ex-nihilo de la précision. Le résultat sera toujours lié à la précision de l'entrée la moins précise.
# Chez moi ça marche ...

Posté par raum_schiff le 18 décembre 2017 à 17:00. Évalué à 2.

Chez moi ça marche :

chez@moi:~$ perl6
To exit type 'exit' or 'ctrlD'
2 - 1.8 - 0.2
0

Ok je ---->[]
# F12

Posté par cosmocat le 18 décembre 2017 à 23:27. Évalué à 3.

0.2 + 0.1 = 0.30000000000000004

(Javascript aussi ;) )
- [^] # Re: F12
  
  Posté par saimn le 19 décembre 2017 à 19:11. Évalué à 7.
  
  Ca me fait penser à http://0.30000000000000004.com/
  - [^] # Re: F12
    
    Posté par Thomas Douillard le 19 décembre 2017 à 19:32. Évalué à 5.
    
    Pour ceux qui essayeraient de retenir le nom de domaine, il y a 15 « 0 »
# Utiliser python comme une calculatrice

Posté par THE_ALF_ le 19 décembre 2017 à 09:32. Évalué à 2.
Un des arguments est que python peut être utilisé comme une calculatrice: c'est possible, mais il faut utiliser ipython, et alors ça marche:
```
In [1]: %precision 8
Out[1]: u'%.8f'

In [2]: 2 - 1.8 -0.2
Out[2]: -0.00000000
```
Le tout est de bien dire que l'on veut une précision à 8 chiffres, par exemple.

# Ca marche aussi... Mais j'ai triché

Posté par Blackknight (site web personnel, Mastodon) le 19 décembre 2017 à 11:04. Évalué à 5.

with Ada.Text_io; use Ada.Text_Io;

procedure Test_Real is
   type mon_real is delta 0.1 digits 3 range 0.0..10.0;

begin
   Put_line (mon_real'Image(2.0 - 1.8 - 0.2));
end Test_Real;

Et voilà, c'était pas compliqué :D

Bon, ok, c'est pas des vrais float, c'est de la virgule fixe

[^] # Re: Ca marche aussi... Mais j'ai triché

Posté par snowball (site web personnel) le 19 décembre 2017 à 19:43. Évalué à 3.

I love Ada ;)

Par contre, comme ce type ne peut gérer correctement que l'addition et la multiplication si tu fais

with Ada.Text_io; use Ada.Text_Io;

procedure Test_Real is
   type mon_real is delta 0.1 digits 3 range 0.0..10.0;

begin
   Put_line (mon_real'Image(3.0*(5.0/3.0)));
end Test_Real;

Au lieu de te sortir 5.0, il te sort 4.8 :)
Ada n'échappe malheureusement pas à la dure loi des math: les décimaux ne forment qu'un anneau et pas un corps (cf https://fr.wikipedia.org/wiki/Corps_(math%C3%A9matiques) et https://fr.wikipedia.org/wiki/Anneau_unitaire )

[^] # Re: Ca marche aussi... Mais j'ai triché

Posté par kantien le 19 décembre 2017 à 21:33. Évalué à 3.

les décimaux ne forment qu'un anneau et pas un corps

mais les rationnels, eux, forment un corps :

let i = Q.of_int 3 in
let j = Q.of_int 5 in
Q.(i * (j / i));;
- : Q.t = 5

:-)

et pour ceux qui aiment les grandes puissances :-P

pow 2017 2017;;
- : Z.t =
3906579755433725744549801881596227303161113974786331742808014316352404207866781011779432579441775839856
9303675091317686485769854660061633900821022073493790844484206374523765685047888592941732567957896337356
8227616903361285861720928485319957896879451656212960334524148908182859288925011902051241977461866923828
5805141216845194646359692773930173890452130301484108603704907663185918027996588306289045733101837983728
0327741427585781943934907066383115733602932268165774793029250948453140731624523723322353528718052018269
2120301190715379956212549955472924854051368917564413054345164976023589951663964251322964845660608570604
8796166013211776531223294858858770618287202956153159070909025445244612929266907435405734058205954066196
6257944413954048938877964772886958563547919584266955161383320262256139624507335975998767755685814334472
7668109856905808726786650150176346749276701349195925308447304906625583450532575618820393030470662264833
6558516764477800855702247701966133115392119659229044822591905333270631043927666037528178491629195538568
4646233989829228655115524936994639184750912047564895374720764672140695409095592363173332472459576462404
5478715399572715756795527704408680018385825873357580378471551915354156980027304848137549295408442862472
0693653228246725934999526408544103045213286398414699798897380577563918878645812125863807732821991332107
8692725905849174024449511921146294190262906996085368959603576478405323143384080388379319554908856556731
5908088452296187414871507326380105914169781913896257814769011618619675396354441317274069735446648347083
9685322479279715610244075962909647201924726552325770866912670386908832937068991644217985561454518613500
7701134281137791471069061199195503527692941530730806868244125447916029477919365350907160212555600592600
7272962151491655468415250273052830341020248623946192353295309806703225240777982731701762090578986703739
2654445594383017249413223433802591420751864046339582968716946613883883630089289092850166742420098475615
2317270292569678698976098602918745091738269938053862716103474442695166725670001543967580405510009441047
9024451590607819278757744377853151071774880174452988351732344899456989727677340502177914005216463498939
1224975421083168091648327063033553252608930068052730798133922253562033497135729065886319850700135166684
4733145986594861443630941669140652635251193447008192851553865779612842872522984948643907872238326400270
9446351625648515268700769721875710891517353990646067011044373315111199657801536917591352152223077856196
7585937746338830459587033526143098022187621420524532754885931847288027594032004390130183176362334815608
9447394688706409250220073258561438553336541717486859130299187109664700107919273459900361576563360385933
3122333043348929219564612801024584337753852145099150440931873218035637881859414477740279483748996993268
2275112162153565809151704179070457180504206906398450192005390333618194565994404545750817781718292706125
0315795328152260735534962635462010401164107240551217025457278458627050670150520970059759320354286441883
9562193815774326236977529972966261410337323664706113705568867451193992124787596100597886820452817195495
5020000700127981453761067545668056756361891835461795143007732741778254730545511658948801939623478920322
8770082758023203322668981651809246482681180422142387309386716816318069955940334056256140580819497179850
3289109355115029124983991018380698424651876194056194282127149997079562496102454369536500984933908739935
9218078735267669384753478767335747571773444969818858147423712760105039603697963834693464702773990816319
6468633747558552065688014667143037574127092846695111905537504841894849764673682096326975021012366606664
0911512953157476533586025093593927262144788949918692089397761431261871877904288178513169823048344238328
2260926947373572812701186712470174863056734569600082502717603716470089407418211450488493170968284198629
6783490416745451108403140493810716002978244023457593747581792541662690908599087691849588468048336655885
3396587675219737345520051486671981990599704130000418965813007224733672096313749475119407724014818508929
5435174820956072871376082451787665388114475605020203864631818413786212782294741026763089059841440923141
7930945943586389649372607933085049704786949757073506895518158455729471986353589128929298803482871893326
4617496210897466235050589604540196335236324754935438515933094258601062968745635884513724512140377812087
9963194898376112183936544916070097706168459234442106763663835372336483086417102786616287430017146620033
9061917369717038449238804553048471167262994455769562518460603987773119867917673314811942882902518952778
4452428862612449080278884098946247489646956505581906115889044658676526114959262438720723867498045450888
6534081710593801600793606848908583050665498686794547787119719610041793592240855296660979007332421390030
6864863782743260903304031347797201921526690054472717597175870696793550292948276452471679162724097409195
9226574012956618385918903583572362462995750127092270563921014720062585125823141782751812643109647530407
8716782263312492623267010550372864203265543683594017627021586771839427413268536947121551554157057847039
0705555753425386733887289438493039753930209202288508301197091965403738469234797311845916566136505553919
5347218311488110187672218257397856026847785288284864740137044134948049741708836860375429551872331945923
3479018544074018576809852216096689981623517895747450086026777001537987227211508713435225975549765258124
8620911163696461283347058836782766473033926630818043689367183277879852758810482761319983832255793901827
2344962449422866729130494318349786441889312965949010199609058366877816005182554357929793751308237195750
8857847106213666743133998010213985877939816967416366993032326406723766280172424741817792379452453933339
1257817923012542366733267840996910829815897656293583783006983681960984012935500660931269066599266830614
9298048454144277912938192170665670364309688124177002766249617224562497248029025108484112804667962930792
7246554758514993911161605836359758869768035926923821402027569506890143101867597868188376534215289800688
4850534058152513832422421443657177753062012002238067078120526881695766025581633086349571371749861205684
2009287332050038500758131655474444270464394270810368067423747143094562220685933183169518338219129062478
9016636657171699043027493231137226070566921703173674515116874346577116337134958859551451311536998094430
8436603930597247181404703316361315782728069013669316656084882670461314916661537994490564226822718247595
6096597627288520629228771111807430370106408669790774313609604966005455290197434687532220849212300973638
4079162882379305241098491933927011736912353861798242466005141298986845754182687703787699360707018541512
82858987245060220859376040188961430411125280662489310010991839503913438177

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

[^] # Re: Ca marche aussi... Mais j'ai triché

Posté par Michaël (site web personnel) le 21 décembre 2017 à 10:39. Évalué à 3.

“On obtient alors le nombre inscrit sur ce carton, qui laisse derrière lui un bon paquet…” dans *Le Professeur Rollin a toujours quelque chose à dire!” :D

[^] # Re: Ca marche aussi... Mais j'ai triché

Posté par Blackknight (site web personnel, Mastodon) le 21 décembre 2017 à 11:11. Évalué à 3.

Alors oui, je suis bien d'accord avec ton explication mais le but de mon exemple était juste de montrer qu'en utilisant la bonne techno, ici un type à virgule fixe, on répond au problème d'origine… Ton exemple montre qu'on ne répond pas à tout avec.

Le tout, c'est de le savoir :)

[^] # Re: Ca marche aussi... Mais j'ai triché

Posté par kantien le 20 décembre 2017 à 00:03. Évalué à 3. Dernière modification le 20 décembre 2017 à 00:05.
Avec Zarith et la précision arbitraire sur les entiers et les rationnels, on résout le problème du journal :
```
#require "zarith"
#install_printer Q.pp_print
#install_printer Z.pp_print

let i = Q.(~$5 / ~$3);;
val i : Q.t = 5/3

Q.(~$3 * i);;
- : Q.t = 5

Q.(of_int 2 - of_string "18/10" - of_string "2/10");;
- : Q.t = 0
```
mais aussi celui d'un de tes anciens journaux ;-)
```
Z.(shift_right one 64);;
- : Z.t = 0
```
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
- [^] # Re: Ca marche aussi... Mais j'ai triché
  
  Posté par Thomas Douillard le 20 décembre 2017 à 12:22. Évalué à 4.
  
  Par contre pour refiler ça comme calculatrice à un CM2, va falloir s’accrocher.
  - [^] # Re: Ca marche aussi... Mais j'ai triché
    
    Posté par kantien le 20 décembre 2017 à 12:41. Évalué à 2.
    C'est sûr que c'est pas très lisible pour un CM2. :-P
    
    L'écriture est lié au système de typage statique OCaml qui n'a pas de mécanisme à la type classes de Haskell. Du coup 2 est toujours interpréter comme étant de type int et ~$ est juste une notation infixe pour la fonction of_int.
    
    L'idée était surtout de montrer qu'il n'y avait aucune difficulté à faire du calcul formel sur les rationnels, avec pour seul limite la capacité mémoire de la machine (python le fait aussi) : c'est juste coûteux en mémoire et plus long en calcul, mais inutile dans la plupart des applications (d'où le recours aux flottants par défaut dans tous les langages).
```
>>> from fractions import Fraction
>>> # attention à bien utiliser des strings
... Fraction('2') - Fraction('1.8') - Fraction('0.2')
Fraction(0, 1)
>>> # avec les floats sa posera aussi problème
... Fraction(2) - Fraction(1.8) - Fraction(0.2)
Fraction(-1, 18014398509481984)
>>> Fraction('3') * Fraction('5/3')
Fraction(5, 1)
```
    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

# Back to the sixties

Posté par .Nicolas. le 19 décembre 2017 à 19:02. Évalué à 1.

COMPUTE RES = 2 - 1.8 - 0.2
DISPLAY RES

0.0
- [^] # Re: Back to the sixties
  
  Posté par .Nicolas. le 19 décembre 2017 à 19:35. Évalué à 2.
  
  Notons au passage que le langage très haut niveau dont il est question :
  - ne permet pas l'injection sql.
  - ne commit pas implicitement (il en a été question récemment dans un autre journal).
  - a une arithmétique décimale comme demandée, à la précision indiquée dans la déclaration des variables.
  - en étant très performant sur les machines qui vont bien (câblées pour traiter nativement un calcul en décimal).
  
  Je tiens à féliciter l'auteur du journal et le trolleur patenté, pour avoir réussi à générer autant de commentaires, tout en ridiculisant toute une communauté d'informaticiens.
  - [^] # Re: Back to the sixties
    
    Posté par gUI (Mastodon) le 19 décembre 2017 à 21:53. Évalué à -1.
    
    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.
    - [^] # Re: Back to the sixties
      
      Posté par .Nicolas. le 20 décembre 2017 à 07:56. Évalué à -1.
      
      Il me semble que tout un chacun peut pousser des idées d'évolution en Python. Aller vers un calcul en décimal, voir gestion des fractions, me semble être assez bien dans la philosophie qu'a pris Python depuis quelques années.
      
      Parce que
      A. Depuis que 1/2 donne 0,5 Python a cassé le comportement standard dans les langages informatiques (avec des problèmes de compatibilité bien plus lourds…). À savoir faire le calcul dans les entiers si les opérandes sont entières (1/2 == 0 donne vrai en C par exemple).
      B. Il n'y a pas d'impact performances critiques. En effet un calcul en décimal n'est rien d'autre qu'un calcul avec des entiers en prenant pour convention un placement de la virgule dans la représentation des nombres.
      C. Le calcul avec des fractions ce sont des calculs élémentaires sur des entiers aussi (et de fait le calcul décimal n'en est qu'un cas particulier). Avec la difficulté supplémentaire qu'il faut savoir décomposer un entier en nombres premiers, ce qui peut grever les performances. Mais dans les cas usuels, de la vie de tous les jours, l'impact sera minime.
      - [^] # Re: Back to the sixties
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 08:06. Évalué à -3.
        
        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.
        
        [^] # Re: Back to the sixties
        
        Posté par Zenitram (site web personnel) le 20 décembre 2017 à 08:22. Évalué à 5.
        
        On va se demander si tu sais lire, tu es un sacré troll de compétition quand même…
        
        Arriver de passer de "le calcul dans les entiers si les opérandes sont entières" à "IEEE-754", chapeau.
        Peux-tu expliquer quel cheminement tordu tu penses nous faire faire pour suivre cette "logique"? Ta blague à jouer au troll est un peu tarabiscotée quand même.
        
        [^] # Re: Back to the sixties
        
        Posté par .Nicolas. le 20 décembre 2017 à 08:32. Évalué à -1.
        
        ~ python2 >> 1/2 0 >> exit() ~ python3 >> 1/2 0.5
        
        [^] # Re: Back to the sixties
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 08:40. Évalué à 0.
        
        Ok j'ai compris, merci :)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Back to the sixties
        
        Posté par .Nicolas. le 20 décembre 2017 à 20:38. Évalué à -2.
        
        Mais de rien ;)
      - [^] # Re: Back to the sixties
        
        Posté par Zenitram (site web personnel) le 20 décembre 2017 à 08:27. Évalué à 3. Dernière modification le 20 décembre 2017 à 08:28.
        
        Depuis que 1/2 donne 0,5 Python a cassé le comportement standard dans les langages informatiques
        
        Quel comportement standard?
        Quel langage?
        
        tu vires comme gUI à penser qu'il existe un "standard"?
        
        float A=1;
        float B=2;
        float C=A/B; //C vaut 0.5 malgré 2 entiers en entrée (tu peux faire un scanf si tu veux pour faire "l'utilisateur rentre l'info comme en Python").
        
        int A=1;
        int B=2;
        int C=A/B; //C vaut 0 ce qui est faux d'après gUI, saloperie de machine à qui ne fait pas ce qu'on pense qu'elle doit faire mais ce qu'on lui demande de faire (ou alors le bug est encore dans l'interface chaise-clavier).
        
        Un jour, on arrêtera de penser qu'il y a un seul et unique "standard" pour les nombres en informatique, la réalité est bien plus compliquée que ça.
        
        [^] # Re: Back to the sixties
        
        Posté par gUI (Mastodon) le 20 décembre 2017 à 08:30. Évalué à -3.
        
        Meeeeeeerde ! Il s'est réveillé !!!
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Back to the sixties
        
        Posté par .Nicolas. le 20 décembre 2017 à 08:41. Évalué à -3.
        
        float a = (float)1;
        
        ou
        
        float a = 1.f;
        
        (de souvenir)
      - [^] # Re: Back to the sixties
        
        Posté par Michaël (site web personnel) le 21 décembre 2017 à 10:45. Évalué à 3.
        
        B. Il n'y a pas d'impact performances critiques. En effet un calcul en décimal n'est rien d'autre qu'un calcul avec des entiers en prenant pour convention un placement de la virgule dans la représentation des nombres.
        
        De temps en temps il y a quand-même un petit calcul de PGCD à faire et les calculs sur les grands entiers ne peuvent se faire sur les registres de la machine, donc il y a des va et viens constants entre les registres et la mémoire: le résultat est une pénalité de performance loin d'être négligeable – même si elle peut être parfaitement acceptable!
# Puisque tout le monde est sûr de détenir la vérité...

Posté par Dring le 20 décembre 2017 à 22:41. Évalué à 6.

…je me lance aussi.

Alors, je lis plein de gens dire que ce serait super coûteux de tout faire en décimal ((au sens type Decimal python). Ben, c'est ce qu'on fait dans la plupart des applications financières et/ou comptables. Et curieusement, ça tient la route. Le type BigDecimal (et son pendant NUMERIC en SQL) sont quand même "pas mal" utilisés si on m'autorise cet euphémisme. Et l'exemple du COBOL est également rafraîchissant dans cet esprit.

Je lis que ce serait une connerie de passer par défaut l'interprétation des litéraux avec une partie décimale comme des décimaux. Pour les langages de bas niveau (C, C++, Rust, Go), je suis 100% d'accord. Pour les langages orientés débutant ou script, c'est moins évident. Pour le python, c'est encore plus difficile : il est aussi bien utilisé par des débutants pour son côté "je tape et je vois tout de suite le résultat" que pour des applications scientifiques avancées.

Mais au final, je pencherais quand même pour un statu quo ; et si c'est vraiment super perturbant pour les débutants de se retrouver avec un résultat qui parfois surprend, il suffit peut-être de simplement revoir les tutoriels pour soit aborder ces notions plus tôt, soit commencer avec les types décimaux fixes.
- [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
  
  Posté par snowball (site web personnel) le 20 décembre 2017 à 23:23. Évalué à 5.
  Et curieusement, ça tient la route.
  
  C'est tout à fait normal que ça tienne la route puisque l'unité est une monnaie et qu'on ne fait jamais de multiplication du type valeur_monétaire_1 * valeur_monétaire_2. On est parfaitement dans le cadre d'utilisation de la virgule fixe que pas mal de langages implémentent notamment Ada et son fameux
```
 type T is delta 0.01 range 0.0 .. 10.0;
```
  qui permet de s'assurer que les résultats sont arrondis à 0.01 dans la plage 0.0..10.0.
  Ce genre de type ne s'utilise pas pour multiplier ou diviser des instances de T par des instances de T (bien que ça soit syntaxiquement correct, les résultats deviennent rapidement aberrants).
  
  Exemple d'utilisation basique: nombre de litres distribués de carburant * prix du litre ou gestion de compte bancaire (additions/soustractions successives de valeurs monétaires). Pour les matheux qui traîneraient sur ce forum, la virgule fixe s'utilise quand on manipule des Q-modules T (addition/soustraction de valeurs de type T ou multiplication de ces valeurs T par des rationnels (pour calculer des pourcentages de valeurs T) mais pas de produit/division entre deux valeurs T.
  - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
    
    Posté par Boa Treize (site web personnel) le 21 décembre 2017 à 08:19. Évalué à 2.
    
    C'est tout à fait normal que ça tienne la route puisque l'unité est une monnaie et qu'on ne fait jamais de multiplication du type valeur_monétaire_1 * valeur_monétaire_2.
    
    Euh, par contre on calcule beaucoup de taux, de taxe ou de bonus/malus d'assurance ! :-)
    - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
      
      Posté par snowball (site web personnel) le 21 décembre 2017 à 09:16. Évalué à 3.
      
      Bah oui mais pas valeur_monétaire_1 * valeur_monétaire_2.
      Ce que tu dis (les calculs de taux, bonus, malus etc) ce sont des opérations du type: rationnel * valeur_monétaire. C'est ce que j'ai précisé avec mon pompeux (?) Q - module T.
      
      Les choses se corsent d'ailleurs quand on souhaite une variance ou un écart type, c'est à dire des calculs quadratiques, sur des valeurs monétaires (c'est d'ailleurs à ce moment là on qu'on fait du cast pour passer à du float pour ensuite repasser à de la virgule fixe). Si tu y penses une seconde, c'est de toute façon nécessaire ce passage momentané au float, puisque la racine carrée (nécessaire pour l'écart type), n'a d'implémentation que chez les floats dans le FPU.
      - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 13:21. Évalué à -5.
        
        Non non les taux, les quantités, les signes monétaires dans la bancassurance sont tous en décimal. Du coup il arrive fréquemment de les multiplier entre eux.
        
        d'implémentation que chez les floats dans le FPU
        
        J'ai bien demandé à Intel de me fabriquer un FPU qui fasse le café… z'ont pas voulu :'(
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 13:30. Évalué à 2.
        
        les taux, les quantités, les signes monétaires
        
        Un taux est un rationnel sans unité.
        Une quantité est un entier sans unité donc un rationnel sans unité.
        Un signe monétaire n'est pas un nombre, donc je vois pas ce que ça vient faire là.
        
        Les SGBD classiques, Excel etc ne réinventent pas la roue quand ils calculent un sinus ou une racine et font un éventuel cast des données qu'elles stockent pour les envoyer sous forme de Float au FPU, qui renvoie un FLoat, et un nouveau cast est nécessaire pour récupérer le résultat dans le SGBD.
        C'est d'ailleurs pour ça que le bug du pentium affectait aussi bien les SGBD que les tableurs.
        
        Pas compris la blague avec la fpu et le café.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 14:03. Évalué à -6.
        
        Valeur monétaires. Je voulais dire valeur monétaire.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 20:15. Évalué à -4.
        
        Pas compris la blague avec la fpu et le café.
        
        Un FPU qui fait du café, c'est plus un FPU mais un CPU. Le CPU lorsqu'il est correctement implanté permet l'accomplissement rapide des tâches attribuées. Mais attention à la congestion, qui provoque alors une brusque augmentation du niveau sonore autour du dit CPU automatiquement suivi d'une brusque diminution de la productivité selon la loi de conservation de l'énergie.
        
        Pour revenir à nos moutons. Un fpu ne sait pas vraiment bien les compter, à moins de salement débiter en tranche saignante le dernier qui aurait eu le mauvais goût de nous arriver entier, bel et bien un entier mouton qui ne connaît point d'epsilon.
        
        Il me faut dire ici que le fpu est comme le CPU : il ne fait guère bon ménage avec le comptage de mouton. Remarque à ce stade qu'il s'agit d'une propriété très recherchée du CPU : c'est même sont utilité première. Tandis qu'avec le fpu c'est une autre histoire : c'est que nous eussions bien aimé qu'il comptât les moutons en entier. Mais rien n'y fit.
        
        Et c'est là tout votre constat, qu'un esprit chagrin eut trouvé fort trivial. À tord certainement car il arracha un joli sourire de mon visage et qu'il fallut me faire source d'effort pour parachever cette démonstration, effort récompensé tant il aura égayé ma soirée. (C'est qu'il en faut peu… pour être heureux… trala…la…).
        
        (Oui je viens de passer une journée de merde)
- [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
  
  Posté par Zenitram (site web personnel) le 21 décembre 2017 à 08:58. Évalué à 2.
  
  Ben, c'est ce qu'on fait dans la plupart des applications financières et/ou comptables.
  
  Besoin spécifique. Choix spécifique. Avec acceptation que la perf est moins important que la précision (cette phrase est importante, et change tout).
  Note que pour la personne voulant faire un calcul "juste", le besoin est spécifique et l'outil adapté existe (une calculatrice)
  
  Et curieusement, ça tient la route.
  
  Oui, on sait tous que des lignes de compta c'est équivalent à plein de calculs scientifiques ou affichage 3D. Ou alors on compare des pommes et des poires.
  
  Pour les langages orientés débutant ou script, c'est moins évident.
  
  Et ben… On demande de le démontrer, justement, et la… Plus personne.
  Dans "langages orientés débutant" il y a "langage", on ne parles plus d'utilisateur, mais de programmeurs. et les débutants doivent un jour commencer à comprendre la notion de float. Mais en fait, personne ne dit qu'il ne faudrait pas changer, pour rappel.
  
  Ce que tu as loupé dans lé débat, et qui est le sujet, est qu'une personne affirme que c'est un bug alors que c'est un choix. Et tant que cette personne dira que c'est un bug à corriger, elle passera juste pour incompétente (au mieux, car si elle insiste elle passera pour incompétente et idiote bornée) et bloquera tout débat (un débat ne pouvant avoir lieu que si basé sur la réalité de choix et non pas un fantasme de bug)
  
  Le choix est peut-être à changer, mais pour débattre sereinement de changer ce choix il faut commencer par comprendre que ce fût et est un choix, et argumenter sur pourquoi il serait mieux de choisir autre chose par rapport aux raisons qui ont fait le choix précédent. Nier les raisons du choix, parler de bug, est juste stupide (et 0% productif, on rigole juste de l'incompétence et on ne débat pas faut de contradicteur sérieux).
  - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
    
    Posté par gUI (Mastodon) le 21 décembre 2017 à 10:13. Évalué à -1.
    
    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.
    - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
      
      Posté par snowball (site web personnel) le 21 décembre 2017 à 10:35. Évalué à 4.
      Mon discours depuis le début c'est "le seul avantage des floats, c'est la perfo.
      
      Totalement faux.
      L'avantage des floats n'est pas que la perfo mais c'est que ça permet de la dynamique. Si tu ne comprends pas ce qu'est la dynamique, il teAvec ça vient rapidement la deuxième question que tu poses aussi : où est le "classique" et où est le "particulier" ? faut apprendre (par exemple ici https://fr.wikipedia.org/wiki/Virgule_flottante )
      
      D'autre part, même si les CPU sont puissants, personne n'est prêt à diviser les performances par 30 (au bas mot) pour du calcul (sur un téléphone, tu diviserais l'autonomie par 2 ou 3 facilement car un smartphone fait du calcul en permanence et pas seulement pour calculer des cos et des sin pendant la géolocalisation du téléphone hein).
      
      Avec ça vient rapidement la deuxième question que tu poses aussi : où est le "classique" et où est le "particulier" ?
      
      La précision que tu réclames est illusoire puisqu'elle n'aurait lieu que sur une infime proportion des nombres manipulés et ce, uniquement si on les additionne ou on les soustrait.
      
      Ce que tu demandes c'est que la science ne comprenne plus rien à ce qu'est l'analyse numérique en croyant, par ignorance pure, à un progrès, mais comme tu n'as pas la niveau de math requis pour le comprendre, tu tournes en boucle.
      
      Remets toi en question et surtout apprends les maths:
      
      précision relative / précision absolue
      
      représentation des entiers puis des réels (virgule fixe et flottante, intérêt inconvénient de chacun)
      
      représentation des nombres en math (écriture propre et impropre en base b)
      
      notion de structure algébrique (groupe, anneau et corps).
      - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 10:51. Évalué à -2. Dernière modification le 21 décembre 2017 à 10:53.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 11:27. Évalué à 4.
        
        IEEE754 est une norme pas un ensemble de nombres.
        L'ensemble des nombres gérés par IEEE754 n'est ni un groupe, ni anneau, ni un corps. Les décimaux forment un anneau mais pas un corps. Les réels forment un corps (donc un anneau).
        
        Je te conseille de lire un cours de structures algébriques pour comprendre tout ça (mais ça prend du temps de digérer tous ces concepts).
        
        D'autre part, si tu veux implémenter en machine les décimaux tu ne pourras jamais, (idem pour les entiers, idem pour les rationnels, idem pour les réels) quelque soit le système que tu utilises, car tu seras limité par la capacité mémoire de la machine. Donc la promesse d'exactitude avec le calcul formel n'est que théorique mais elle n'est pas effective (on étend juste un peu les nombres pour lesquels les calculs sont exacts en augmentant la taille de la mantisse).
        
        Les seuls ensembles de nombres pour lesquels une machine de Turing calcule de façon exacte sont les anneaux modulaires (c'est ce que représente int ou longint).
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 11:38. Évalué à -4.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 13:00. Évalué à -3.
        
        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 ?
        
        Ça c'était petit !
        
        Je te souhaite de la patience et une bonne carapace ;)
  - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
    
    Posté par gUI (Mastodon) le 21 décembre 2017 à 10:36. Évalué à -1.
    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.
    - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
      
      Posté par snowball (site web personnel) le 21 décembre 2017 à 11:30. Évalué à 6.
      
      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.
      
      Note que tu es moins exigeant avec d'autres résultats arrondis (qui sont tout aussi faux) mais tu es exigeant uniquement avec les erreurs d'arrondis que tu vois. C'est un manque de recul mathématique qui te fait agir de la sorte.
      - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 11:47. Évalué à -2.
        
        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.
      - [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 12:07. Évalué à -5.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 21 décembre 2017 à 12:29. Évalué à 4.
        
        Sûrement. Dis-moi c'est dans les anneaux ou les corps que tu justifies ce comportement actuel ?
        
        peut être que tu comprendrais mieux ton erreur si tu explicitais ce que tu as réclamé à la machine.
        
        (2.0 +/-e) - (1.8 +/-e) - (0.2 +/-e) == (0.0 +/-e)
        
        Tant que tu refuses de comprendre que ton 0.2 n'est pas 0.2, mais (0.2 +/-e), et qu'il en est de même pour tous les nombres 'float' on avancera pas.
        
        En 4e on aborde les encadrements, tu devrais aller relire ces cours.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 14:49. Évalué à -3.
        
        (2.0 +/-e) - (1.8 +/-e) - (0.2 +/-e) == (0.0 +/-e)
        
        Ben ça devrait renvoyer ~vrai~ avec la confiance associée (souvent en %) sous l'hypothèse choisie (très souvent une distribution gaussienne).
        
        Mais l'effort était louable…
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 21 décembre 2017 à 15:11. Évalué à 4.
        
        Ben ça devrait renvoyer ~vrai~ avec la confiance associée
        
        On est pas sur un langage quantique, on a True ou False, pas des %True, c'est un peu comme si tu disais que 10+x > 0 est vrai dans la majorité des cas donc je revoie vrai.
        
        Par ailleurs l'égalité est fausse. ce qui est vrai, c'est (2.0 +/-e) - (1.8 +/-e) - (0.2 +/-e) == (0.0 (+/-4*e))
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par Michaël (site web personnel) le 21 décembre 2017 à 16:51. Évalué à 2.
        
        Par ailleurs l'égalité est fausse. ce qui est vrai, c'est (2.0 +/-e) - (1.8 +/-e) - (0.2 +/-e) == (0.0 (+/-4*e))
        
        Ce n'est pas la bonne égalité, en notant φ(x) = μ(x) 2^τ(x) (avec 0<= μ(x) < 1) le flottant représentant la représentation de x en virgule flottante ce qui est garanti c'est que |φ(x) - x | <= ε 2^τ(x) donc du coup (en tenant compte du fait que 2 est bien représenté!) on a plutôt un truc du genre
        
        4(0.5) - 2(0.9 +/- ε) - (0.2 +/- ε)
        
        pour aller plus loin dans l'estimation il faudrait considérer l'arbre effectivement utilisé pour faire le calcul!
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 17:51. Évalué à -5.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par Michaël (site web personnel) le 21 décembre 2017 à 18:02. Évalué à 7.
        
        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".
        
        On pourrait mais ce n'est pas le choix qui a été fait par la plupart des langages, mais au lieu d'argumenter réellement en cherchant à faire une liste des avantages et des inconvénients que pourrait introduire ce changement, par exemple Python, tu te bornes à dire “regardez les floats ne marchent pas comme l'arithmétique exacte” – ce qui est loin d'être une nouveauté – et à jouer les incompris – ce qui est pénible.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par Michaël (site web personnel) le 21 décembre 2017 à 16:08. Évalué à 7.
        
        Sûrement. Dis-moi c'est dans les anneaux ou les corps que tu justifies ce comportement actuel ?
        
        Le comportement que tu pointes n'a rien à voir avec les structures algébriques, c'est encore une manifestation du fait que Python utilises des nombres en virgule flottante pour effectuer ce calcul que tu lui demandes. Vérifier l'égalité de deux nombres en virgule flottante n'est presque jamais la bonne chose à faire et à la place on étudie la taille de la différence, soit en unité absolues soit, plus communément en unités relatives.
        
        Tout cela est expliqué dans le livre de Knuth (Art of Computer Programming) et certainement dans beaucoup d'autres sources.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 17:56. Évalué à 4.
        
        Je ne comprends toujours pas comment tu peux argumenter l'utilisation de IEE-754 vs Decimal avec des théories mathématiques.
        
        Bah oui j'ai bien vu que tu ne comprenais pas ! Ce ne sont pas des "théories" mathématiques au sens où ça serait "magique" ou "fumeux". Ce sont des résultats liés à du raisonnement très simple mais qui prennent du temps à digérer. En gros, il te faut apprendre un minimum de math si tu veux parler de nombres et d'informatique.
        
        Je t'ai donné une liste de concepts fondamentaux et indispensables sans lesquels tu ne pourras jamais rien comprendre au "problème" que tu soulèves (qui n'est un problème que pour toi parce que tu n'as pas accès aux concepts). Attention, comprendre ces concepts prend du temps et de l'énergie. Ca ne se comprend pas en 5mn (sauf si tu as des aptitudes exceptionnelles).
        
        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.
        
        Accessoirement, apprendre ces choses à des élèves ingénieurs est mon métier, et j'espère que tu pourras tirer quelque chose de ce cours que j'ai tapé il y a quelques années et que je donne aux étudiants de 2ème année (attention, il ne parle pas de structures algébriques, qui sont des notions qu'ils ont vu en première année):
        
        http://cyril.bredel.free.fr/ReelsEnMachine.pdf
        
        Bonne lecture.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 18:19. Évalué à -3.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 18:57. Évalué à 3.
        
        Ce n'est pas moi qui ai raison, c'est les maths. Moi je ne fais que les étudier et les transmettre comme je peux.
        
        De mon côté, je ne prétends pas que la science devrait progresser en me basant sur mon ignorance. J'essaye de t'expliquer quels sont les concepts à travailler pour se lancer dans une conversation de ce type.
        
        Que Python implémente ceci https://en.wikipedia.org/wiki/Decimal32_floating-point_format dans une future release ne changera absolument rien à ce que je dis.
        
        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. comme le decimal de python etc tout simplement pour les raisons déjà 10 fois évoquées avant.
        
        Au fait tu râles quand Python sort 0.2+0.8-1.0 != 0 mais râles-tu quand la calculatrice se goure en faisant 1.23456789×1.23456789=1,524157875 ? (résultat évidemment faux puisque le dernier chiffre devrait être 1). En fait tu ne râles que sur les erreurs des calculatrices que tu vois (alors qu'elle donne un résultat juste à $10^{-17} près$ , parce que tu n'as pas compris qu'une calculatrice ne donne quasiment jamais un résultat exact sauf dans de très rares cas adaptés au format BCD. Et ça c'est parce qu'il te manque des concepts.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 19:12. Évalué à -6.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 19:45. Évalué à 6.
        
        As tu au moins compris que lorsque tu utilises une calculatrice sur de petits décimaux pour faire les opérations élémentaires elle donne presqu'à chaque fois un résultat faux mais que tu ne râles que quand tu détectes ces erreurs de visu ? Toutes les autres erreurs, qui se produisent presqu'à chacun de tes calculs, ne te dérangent pas sous prétexte que tu les détectes pas ?
        
        L'approximation à la 17ème décimale faite par python te fait crier au bug ou au scandale depuis plus de 100 posts mais celle faite par ton module Decimal de python:
        
        >>> from decimal import * >>> Decimal('1.23456789987654')**2 Decimal('1.524157899405570494147242372')
        
        qui se vautre sur le carré d'un décimal donné à la 15ème décimale ne te choque pas ?
        
        C'est bien ce que je dis, tu ne râles que sur les approximations que tu détectes. C'est incohérent et ridicule.
        
        La solution que tu veux, c'est tout simplement d'arrondir la sortie utilisateur comme le fait excel ou calc. Pas la peine de demander une révolution pour ça, une petite fonction python le permet déjà.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 20:05. Évalué à -3.
        
        T'en redemandes ? Allons-y doucement…
        
        J'ai toujours dit que j'étais bien conscient que Decimal était limité à 28 chiffres après la virgule (c'est dans la doc), tu me donnes un exemple à 30 chiffres après la virgule, donc ça fait pas trop avancer le shmilblick
        
        Là tu es limité par l'affichage, demande la totalité de la représentation interne par repr() (faudrait lire la doc un peu) et tu verras tes 28 décimales (float à côté c'est de la gnognotte)
        
        Decimal a la decence de te garantir que 1.23456789987654 sera exactement représenté, alors que IEEE-754 ne te le garantie pas (si tu es si fort, dis-moi si c'est le cas) (et bien sûr je veux l'explication, trop facile de tester). C'est plutôt ça qui me choque à la base.
        
        Une fois ce chiffre saisi et correctement stocké en mémoire (c'est pas le boulot d'un ordi ça à la base ?) je sais ce que je peux y faire dessus sans perdre de précision (je peux t'affirmer que je peux le diviser encore par 10, je sais que le résultat sera exact. Promis. Tu peux en dire autant en float ?
        
        Ton exemple a généré un signal te disant que ce n'est plus exact, tu aurais pu l'utiliser (mais faut avoir lu la doc avant)
        
        Mais surtout : 0.1, en décimal, c'est possible et c'est l'objet de ce journal (et rien d'autre)
        
        En échange de tous ces avantages de Decimal, peux(tu me donner un seul avantage de faire le même calcul en float, autre que la rapidité ?
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 21:01. Évalué à 10.
        
        J'ai toujours dit que j'étais bien conscient que Decimal était limité à 28 chiffres
        
        Et donc si ça se vautre à partir de la 28ème décimale c'est pas grave mais à la 17ème c'est horrible. Mais si c'est ça le problème, fallait le dire ! Tu n'as qu'à bosser avec des floats sur 128bits en IEEE754 comme ça, tu gagneras sur tous les plans: ce sera plus précis que ton module decimal et largement plus performant. Et pour ton problème d'affichage des décimaux à arrondir tu le fais juste à l'affichage et comme ça tu seras rassuré. Tu vois ton problème est réglé ! Là tu as tout ce que tu veux (pour info ce type est inclus dans la lib numpy de python), pas la peine de toucher à la représentation interne qui est très performante,
        
        Mais surtout : 0.1, en décimal c'est possible
        
        Ah bah oui, la voilà la révolution, on se met en BCD comme sur les calculatrices depuis les années 70 pour pouvoir rentrer 1/10 dans la machine sans choquer celui qui voudrait continuer à croire que la machine ne fait jamais d'approximations ! Mais évidemment pour autre chose que 1/10 ça plantera, mais on s'en fout parce que dans la vie, on divise des quantités que par 10 c'est bien connu, on manipule exclusivement des décimaux :) Les décimaux c'est tellement important quand on fait des calculs. Pas de tiers, pas de sixième, pas de septième, pas de neuvième….mais les dixièmes, les amis, c'est pri-mor-dial !
        
        je peux t'affirmer que je peux le diviser encore par 10, je sais que le résultat sera exact.
        
        Ah la division par 10… celle qui permet de tout faire dans la vie, qui a un intérêt magique et tellement indispensable qu'il faut, pour elle un traitement spécial, et pour laquelle il est obligatoire d'avoir une représentation exacte au point de devoir multiplier les coûts de calcul par 50, consommer des mégawatts dans le monde entier, pour que, ouf, les décimaux s'affichent de façon exacte, enfin pas pour tous, mais au moins pour quelques un d'entre eux.
        
        ….à moins qu'on ne se contente d'arrondir la sortie utilisateur au décimal le plus proche non ? C'est le choix de ton tableur, utiliser des floats et arrondir pour entretenir l'illusion :)
        
        Bon alors si tu veux savoir pourquoi on bosse en base 2 avec des float et non en base 10 avec le format BCD, c'est tout simplement parce que si tu veux stocker un chiffre en base 10 il te faut minimum 4 bits alors qu'avec 4 bits tu pourrais stocker 16 nombres différents. Tu perds donc 37,5% d'espace mémoire avec ce type de représentation. On pourrait aussi ajouter qu'en algorithmique il est ultra fréquent de diviser par 2 (ne serait-ce que pour tous les algos dichotomiques). alors que diviser par 10 n'est utile que pour des sorties utilisateur décimales….
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 21:37. Évalué à -5.
        
        Et donc si ça se vautre à partir de la 28ème décimale c'est pas grave mais à la 17ème c'est horrible.
        
        Oui. Pour rappel, la sitaution actuelle, float, se vautre dès la première.
        
        Tu n'as qu'à bosser avec des floats sur 128bits en IEEE754 comme ça, tu gagneras sur tous les plans
        
        Non. On ne pourra toujours pas représenter exactement 0.1 et surtout 2 - 1.8 - 0.2 continuera à retourner autre chose que zéro (ce qui est l'objet du journal, je le rappelle encore une fois, mais t'écoutes rien)
        
        Et pour ton problème d'affichage des décimaux
        
        Mon problème c'est pas l'affichage, c'est le calcul mathématique (tu sais le truc avec les anneaux).
        
        Ah bah oui, la voilà la révolution, on se met en BCD comme sur les calculatrices depuis les années 70
        
        C'est une possiblité qui m'irait. Mais depuis la recherche a fait quelques progrès, par exemple Decimal. Ne dénigre pas stp les avancées des scientifiques.
        
        Mais évidemment pour autre chose que 1/10 ça plantera
        
        Le rationnal est une autre possibilité qui m'irait bcp et qui ouvrirait sur le fameux 1/3 que tu ne peux pas te sortir de la tête (et que je n'ai jamais revendiqué).
        Mais tu sors du cadre du journal où on parle de soustractions et de calculs de CE2 (ça c'est moi qui est tenté de généraliser le pb du journal). En CE2 on n'essaie pas de représenter des rationnels non décimaux par des représentation décimales.
        
        Les décimaux c'est tellement important quand on fait des calculs. Pas de tiers
        
        1/3 c'est pas représentable en float non plus.
        
        multiplier les coûts de calcul par 50
        
        Tu le sors de quel chapeau ? Perl a fait ce choix (et même plus chaud : rationnal), Python a parlé de le faire (j'ai le lien sous le coude je rappelle), tu iras leur dire qu'ils font n'importe quoi.
        
        consommer des mégawatts dans le monde entier
        
        Le SIDA c'est pas moi, je promets.
        
        à moins qu'on ne se contente d'arrondir la sortie utilisateur au décimal le plus proche non ?
        
        Non. Je veux (2.0 - 1.8 - 0.2 == 0.0) => True (ça aussi je l'ai dit et répété)
        
        C'est le choix de ton tableur, utiliser des floats et arrondir pour entretenir l'illusion :)
        
        C'est peut-être leur choix, mais c'est pas certain. Je ne serais pas si sûr si j'étais toi (mais bon, t'es un mec vachement sûr de lui aussi). Pour rappel un tableur n'est pas spécialiste de gros calculs mais de calculs destinées à être affichés à l'utilisateur. En tous cas, c'est pas le choix que je ferais. Mais j'ai des idées à la con aussi. (cherche pas l'implémentation de LibreOffice, on s'en branle, c'est juste pour te faire chier)
        
        Bon alors si tu veux savoir pourquoi on bosse en base 2 avec des float et non en base 10 avec le format BCD, c'est tout simplement parce que si tu veux stocker un chiffre en base 10 il te faut minimum 4 bits alors qu'avec 4 bits tu pourrais stocker 16 nombres différents.
        
        Oui, et parce que ça va bcp plus vite. Je sais tout ça, t'inquiètes pas.
        
        On pourrait aussi ajouter qu'en algorithmique il est ultra fréquent de diviser par 2 (ne serait-ce que pour tous les algos dichotomiques). alors que diviser par 10 n'est utile que pour des sorties utilisateur décimales….
        
        Alors je te spoile : la valeur de départ que tu as toi-même utilisé, je peux la diviser par 2, encore la diviser par 2, et faire ça des dizaines de fois, je serai toujours en valeur exacte. Toi, tu ne m'as toujours pas dit si ta valeur de départ était déjà représentable en IEEE-754. Par contre je suis d'accord ça ira moins vite, mais ça aussi je l'ai déjà dit un paquet de fois.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 22:31. Évalué à 6.
        
        Oui. Pour rappel, la sitaution actuelle, float, se vautre dès la première.
        
        Mais tu n'as toujours pas lu que ce n'est pas vrai ??? La preuve:
        
        >>> 2.0 - 1.8 - 0.2 -5.551115123125783e-17
        
        C'est à la 17ème décimale qu'il y a l'erreur ! Comprends-tu le sens de e-17 ? Je finis par avoir un doute là…
        
        Mon problème c'est pas l'affichage, c'est le calcul mathématique (tu sais le truc avec les anneaux).
        
        Bah non, ton problème c'est l'affichage du résultat qui n'est pas arrondi au décimal le plus proche sinon tu gueulerais contre excel ou libreoffice puisque excel et libreoffice utilisent des floats pendant les calculs (tu sais l'anneau là) mais arrondissent au moment de l'affichage pour ne pas choquer les profanes en mathématiques.
        
        1/3 c'est pas représentable en float non plus.
        
        Bah oui ça tombe bien parce qu'on fout vu que ça reviendrait à vouloir que les 1/n soient tous représentables exactement en machine ce qui n'est pas possible dans une base donnée.
        
        multiplier les coûts de calcul par 50
        
        On va compter si tu veux.
        Sur un proco intel, une multiplication entre deux floats 64 bits prend en moyenne 6 cycles d'horloge.
        Si tu veux créer un type en python spécial, tu vas commencer par allouer dynamiquement un objet pour stocker ta structure (déjà rien que là, ça coûte cher). Tu vas devoir multiplier tes numérateurs (qui sont des int sur 64 bits si tout va bien mais qui peuvent être des entiers longs non gérés par la FPU) et tes dénominateurs (idem). Le coût à ce stade n'est que du double. Sauf que derrière il faut faire l'algo d'Euclide pour calculer le pgcd afin de simplifier ton numérateur et ton dénominateur (en moyenne une bonne dizaine de multiplications et la même chose en soustraction). On est donc à plus de 12 multiplications. Une fois que c'est fait il faut diviser ton numérateur et ton dénominateur par le pgcd obtenu par Euclide. chacune des deux divisions coûte environ 8 multiplications sur 64 bits. Au bas mot, si tout se passe bien et si tu comptes bien, tu vas tourner autour de 30 multiplications, une douzaine de soustractions de deux cycles chacune, sans parler des boucles nécessaires au pgcd, aux tests de non nullité à chaque tour, aux empilements/désempilements liés à chaque appel des sous routines. Je ne parle pas non plus de la gestion des exceptions. Je dirais en fait que mon facteur 50 est finalement trop léger.
        Perl c'est du scripting, il ne vise pas du tout le même champ d'applications que ce que propose Python (qui n'est déjà pas un modèle de performance).
        
        [Excel, FPU, tout ça tout ça….]C'est peut-être leur choix, mais c'est pas certain.
        
        Bah si c'est certain. C'est même le cas depuis que les FPU ont été démocratisés https://en.wikipedia.org/wiki/Pentium_FDIV_bug
        Cette page est bien la preuve que les tableurs utilisent la FPU puis arrondissent au décimal le plus proche pour les béotiens qui veulent du décimal tout rond à l'affichage.
        
        Toi, tu ne m'as toujours pas dit si ta valeur de départ était déjà représentable en IEEE-754
        
        Pourquoi je dirais un truc comme ça puisque ça n'a aucune espèce d'importance ? Qu'est-ce que ça peut bien faire ? Si ça ne l'est pas exactement en interne, je formaterai (si j'en avais besoin) la sortie utilisateur pour que ce soit joliment arrondi et c'est tout.
        
        Moralité, on a répondu à ton problème:
        
        Tu utilises des floats sur 128 bits (via numpy) tu formates la sortie utilisateur pour arrondir au décimal le plus proche et voilà tu as tout ce que tu veux, avec de bonnes perfs et une meilleure précision que ton module Decimal en python (omg !). Y a rien à révolutionner, juste à apprendre comment fonctionnent les supers outils dont on dispose.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 23:03. Évalué à -4.
        
        Mais tu n'as toujours pas lu que ce n'est pas vrai ??? La preuve:
        
        Oui, je m'ai trompé, je l'ai dit dans l'autre, on a croisé les conversations. IEEE se trompe sur la représentation d'un décimal qui a un chiffre après la virgule. Pardon. Mais l'erreur sur 0.1 est plus petite que 1/10, c'est une bonne nouvelle.
        
        Bah non, ton problème c'est l'affichage du résultat
        
        Je suis pas fan quand tu me dis ce que je pense, surtout quand c'est pas ça.
        
        J'en sais rien pour les tableurs, c'est pas trop le sujet ici. Si tu fais 2.0 - 1.8 - 0.2 == 0, il te dit VRAI ton tableur ? Si oui, il me va très bien. Si non, c'est le même combat en effet. Je ne pense pas que ce soit de l'affichage. Je te parle exactitude, tu me réponds affichage. C'est pénible.
        
        Par contre certains en avaient marre en effet des pb d'affichage dont tu parles et ont ajouté du code (chacun jugera de l'élégance) pour cacher la misère de IEEE-754 : https://bugs.python.org/issue1580 (j'ai déjà donné ce lien, mais je ne suis pas sûr que tu sois allé voir).
        
        Bah oui ça tombe bien parce qu'on fout vu que ça reviendrait à vouloir que les 1/n soient tous représentables exactement en machine ce qui n'est pas possible dans une base donnée.
        
        Pour peux que n soit représentable raisonnablement (style un entier sur 64 bits, c'est déjà pas mal, on en trouve des n), si, on peut le représenter en machine. Facilement en plus. Et sans erreur. Le type Rationnal existe pour ça. Ensuite en BdD je sais pas (qu'estce que ça vient foutre là ?), mais c'est pas le sujet ici, on parle de Python et de soustractions. (t'es agaçant à vouloir tout généraliser pour ensuite démontrer que tout n'est pas généralisable).
        
        On va compter si tu veux.
        
        Non, épargne-moi ça stp. Demande plutôt à Perl ce qu'ils en pensent, eux qui ont fait ce choix . Il me semble même qu'il y a un lien dans cette page…
        
        Bah si c'est certain.
        
        Un très bon point pour toi !!! On peut revenir maintenant à Python et sa soustraction à 1 décimale avec un résultat faux ?
        
        Pourquoi je dirais un truc comme ça puisque ça n'a aucune espèce d'importance ?
        
        Tu ne vas pas renier les anneaux quand même ? Après m'avoir bassiné par l'analyse et les grandes théories, tu vas maintenant me dire que… boarf… 0.1… finalement qu'est-ce que c'est ? Qui ça intéresse ? Du moment que c'est à 10^-17 près… ça suffit non ?
        
        Je reviens à ce que je dis : s'il-te-plait, donne moi un avantage du float par rapport au Decimal mis à part la perfo.
        
        Si ça ne l'est pas exactement en interne, je formaterai (si j'en avais besoin) la sortie utilisateur pour que ce soit joliment arrondi et c'est tout.
        
        Si ça ne l'est pas en interne, il y audra des erreurs de calcul derrière. L'anneau, il veut pas ça.
        Tu te limites au print, mais n'oublie pas : 2.0 - 1.8 - 0.2 == 0.0 => False
        
        Je trouve que ça fait tache dans un langage moderne généraliste.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 23:24. Évalué à 2.
        
        Voilà, on a fait le tour. Je ne peux plus rien pour toi. Amuse toi bien.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par kantien le 21 décembre 2017 à 23:32. Évalué à 4.
        
        Je reviens à ce que je dis : s'il-te-plait, donne moi un avantage du float par rapport au Decimal mis à part la perfo.
        
        Dès que l'on quitte les opérations algébriques de base (addition, multiplication, soustraction) et qu'on en vient aux fonctions transcendantes¹ (sinus, cosinus, logarithme, exponentielle…, voir le commentaire de Michaël). Si tu reprends l'article de Guido sur les raisons du changements pour la division sur les int :
        
        (This recently happened to me in a program that draws an analog clock – the positions of the hands were calculated incorrectly due to truncation, but the error was barely detectable except at certain times of day.)
        
        Pour dessiner une horloge analogique, il faut faire de la trigonométrie et donc utilise les float. ;-)
        
        même avec les nombres algébriques (racines de polynômes à coefficients entiers) cela devient vite injouable de calculer exactement et de les comparer. ↩
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 22 décembre 2017 à 09:22. Évalué à 3.
        
        Pour dessiner une horloge analogique, il faut faire de la trigonométrie et donc utilise les float. ;-)
        
        Oui mais comme en python tu ne peux pas préciser le type de paramètre, il a fallu changer tout python, en perl6 on peut préciser le type de paramètres ;)
        
        (par contre perl6 est très différent du perl5)
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par kantien le 22 décembre 2017 à 14:57. Évalué à 2.
        
        il a fallu changer tout python
        
        Non, juste redéfinir une fonction sur un type de base. Je n'appelle pas cela changer tout le langage. ;-)
        
        Python 2.7.13 (default, Nov 24 2017, 17:33:09) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import division >>> 2/3 0.6666666666666666 >>> 2//3 0
        
        Pour la question de l'absence de typage statique, c'est loin d'être le seul défaut de python.
        
        Pour rester sur la question de la rigueur mathématique, de toute façon, pour moi, dès qu'on sort de la programmation fonctionnelle avec typage statique, on n'est déjà plus très rigoureux (je tolère à la rigueur les effets de bords et le code impure, c'est-à-dire les valeurs mutables, mais au-delà de ça, on est trop loin de la conception mathématique du calcul).
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 22 décembre 2017 à 15:18. Évalué à 2.
        
        Sauf que changer un type de base qui est utilisé dans les binding C, c'est jouer à l'équilibriste en haut d'un immeuble de 42 étages par vent de force 5.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par kantien le 22 décembre 2017 à 17:17. Évalué à 2. Dernière modification le 22 décembre 2017 à 17:21.
        
        Sauf que changer un type de base qui est utilisé dans les binding C
        
        Je ne vois pas où ils ont changé un type de base, ils ont juste changé la signature d'une fonction. Avant on avait :
        
        int div(int i, int j)
        
        maintenant on a :
        
        float div(int i, int j)
        
        C'est juste le type de sortie d'une fonction qui a changé, non la représentation en mémoire d'un type de base. C'est un léger changement d'interface et de sémantique pour une fonction, avec une autre fonction existante (//) ayant le même comportement que l'ancienne, pas de quoi fouetter un chat ni jouer à l'équilibriste en haut d'un immeuble de 42 étages par vent de force 5. ;-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par Michaël (site web personnel) le 22 décembre 2017 à 02:23. Évalué à 5.
        
        Je te parle exactitude, tu me réponds affichage. C'est pénible.
        
        Pour la machine un nombre flottant est un nombre entier fois une puissance de deux et si on veut afficher cela en base 10 il faut déterminer les chiffres à afficher… ce qui se fait avec une certaine précision!
        
        Je reviens à ce que je dis : s'il-te-plait, donne moi un avantage du float par rapport au Decimal mis à part la perfo.
        
        Je l'ai déjà écrit ailleurs mais apparemment cela mérite d'être répété: en calcul scientifique on ne sait en général que faire du calcul approché, et la plupart des nombres ne sont pas décimaux, ni même rationnels, on ne travaille qu'avec des nombres qui ne sont pas représentables exactement dans la machine (sauf si on se contente de leur donner un nom, mais, sans surprise, on ne sait pas faire grand chose de ce nom). Du point de vue strictement spéculatif, puisqu'on peut représenter un flottant par un décimal et les utiliser dans les calculs mais ce faisant on ne va pas très loin. Par exemple dans une simulation de type LIBOR Market Model pour simuler la “zero curve” pour les 25 prochaines années on va faire un calcul du type u[i][0] = donné initiale pour i et u[i][j+1] = whatever * exp(whatever* u[i][j] + whatever) + whatever où les divers whatever désignent tous des expressions distinctes. Quelle taille τ(x) peut bien avoir un nombre décimal x sortant d'un tel système? Mettons qu'on calcule l'exponentielle en sommant les N = 20 premiers termes de la série (ce qui est une très mauvaise façon de calculer l'exponentielle loin de zéro!), on a (Sterling) τ(n!) ∼ n log(n) et τ(xⁿ⁾ ∼ n τ(x) du coup vite fait τ(exp x) ∼ N (log(N) + τ(x)) / 2 et quand j'utilise plus de 9000 itérations (au moins un point par jour pour les 25 prochaines années) de la formule avec les whatever on se retrouve avec un terme dominant τ(final) en N log⁹⁰⁰⁰ (N) et en se souvenant qu'un gigabit c'est à peine 2⁹ octets, on voit qu'on aurait le mal plus fou à ne stocker qu'un résultat de ces itérations… mais on veut en calculer des centaines de milliers! Si on peut tout faire tenir sur 64 bits, c'est pas plus mal!
        
        Donc pour récapituler: les nombres rationnels en machine permettent de faire de l'arithmétique exacte, mais sont lents et prennent beaucoup de place et on ne peut rien calculer d'autre que des fractions rationnelles, tandis que les floats ne savent rien calculer exactement mais sont rapides et petits.
        
        Il existe des systèmes qui peuvent utiliser indifféremment les floats et les rationnels, comme par exemple Common Lisp (depuis au moins 1984!), Maple, etc. mais ils ne sont pas faciles à manier – ce qui est précisément l'inverse du but que tu sembles poursuivre.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 09:34. Évalué à -4.
        
        en calcul scientifique on ne sait en général que faire du calcul approché
        
        Si tu étais passé par le CE2 (au lieu de partir direct en Mat'Sup), tu saurais qu'il existe aussi des calculs simples qu'on peut faire exactement.
        
        Je pense que c'est le rôle d'un langage généraliste comme Python de le proposer TANT QUE C'EST POSSIBLE, par exemple dans la soustraction dont parle le sujet du journal (pour y revenir encore et encore…)
        
        Passer de "Decimal" à "float" automatiquement dès que le besoin s'en fait sentir (par exemple lorsque un scientifique veut calculer la distance Terre / Alpha du Centaure avec des allumettes) permet de tenir l'exact si c'est possible (et éviter ce que je considère ici comme anormal : 2.0 - 1.8 - 0.2 == 0.0 => False) et permet aussi aux scientifiques de faires des trucs 'achement balaises, toujours avec le même langage. GENERALISTE je dis.
        
        Je ne veux pas éradiquer IEEE-754, je voudrais qu'on ne l'utilise que quand il est vraiment nécessaire. En dernier recours. Que ce ne soit pas le reflexe de "chiffre à virgule => float IEEE-754". D'autres implémentations existent. Et elles ne font pas d'erreur de calcul sur une soustraction de CE2.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par Dr BG le 22 décembre 2017 à 09:52. Évalué à 6.
        
        Dans un langage impératif, changer de type suivant le résultat ne me semble pas une bonne idée, le programmeur ne peut plus prévoir ce qu'il va obtenir à la fin.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 10:09. Évalué à -3.
        
        Entièrement d'accord.
        
        http://linuxfr.org/users/reynum/journaux/humour-vers-un-monde-different#comment-1724453
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par Dr BG le 22 décembre 2017 à 10:16. Évalué à 3.
        
        Mouais, tu dis quand même que c'est chiant (« 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 »), mais que c'est pas grave (« Il peut toujours récupérer le signal de perte d'exactitude, il saura qu'on a basculé (ou tester le type()) »).
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 10:23. Évalué à -2.
        
        Alors ouvrons tous ensemble notre esprit, et demandons-nous comment faire !
        
        Comment fait Perl par exemple ? Pas de typage dynamique, ils gardent leur rationnal tout le temps et laissent "float" seulement à ceux qui l'ont explicité ? C'est une autre possibilité. Je sais pas… mais ne coupons pas court à toute discussion du moment qu'on n'a pas TOUS les détails techniques réglés.
        
        L'idée de la discussion c'est :
        - ne pas faire de calculs exacts sur des opérations de CE2, ça fait tache oui ou non (j'ai sorti des patchs Python et un fil de conversation qui prouve que les concepteurs de Python pensent que oui)
        - a-t-on des solutions techniques pour le faire oui ou non (Perl l'a fait, on peut réfléchir à Python)
        - quel est l'intérêt de le faire (j'ai tout simplement parlé de calculs exacts, c'est suffisant pour moi. autrement dit, c'est pour effacer la tache qui est globalement acceptée - voir ci-dessus)
        - quel est l'inconvénient de le faire : les perfos (j'attends toujours un autre contre-argument pour ma part)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 22 décembre 2017 à 10:48. Évalué à 4.
        
        a-t-on des solutions techniques pour le faire oui ou non (Perl l'a fait, on peut réfléchir à Python)
        
        Hou la Perl6 le fait, pas Perl5, ce qui est très récent, voire limite expérimental. Par ailleurs Perl6 permet de préciser le type de paramètre, ce que ne permet pas python
        
        a-t-on des solutions techniques pour le faire oui ou non
        
        Perl6 est incompatible Perl5, il faut traduire tous les programmes.
        
        quel est l'inconvénient de le faire
        
        retester l'ensemble des codes python pour migrer.
        
        fragmenter encore python (on a encore du python2)
        
        Avoir du code qui va péter parce qu'on aura silencieusement modifié un type d'une variable…
        
        Et quel est le gain de le faire ?
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 10:58. Évalué à -4.
        
        Et quel est le gain de le faire ?
        
        http://linuxfr.org/users/reynum/journaux/humour-vers-un-monde-different#comment-1724770
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 22 décembre 2017 à 11:14. Évalué à 6.
        
        Non ça ne répond pas à la question. Si tu veux tu calcul exact, on a déjà Decimal. Quel est le gain de prendre par défaut décimal par rapport à un calcul en virgule flottante. Je ne vois par l'intérêt d'avoir un calcul exact par défaut dans Python; à par se branler la nouille.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 11:30. Évalué à -4.
        
        Je ne vois par l'intérêt
        
        C'est ton avis et pas le mien. Ni celui du créateur Python. Du coup je me sens un poil plus en position de force depuis que j'ai trouvé ça.
        
        Après je suis étonné que celui qui me bassinait avec les corps et les anneaux ne comprenne pas l'intérêt de calculs justes par exemple.
        
        à par se branler la nouille.
        
        Accessoirement, ça évite des comportements comme "2.0 - 1.8 - 0.0 == 0.0" => False.
        
        On a beau avoir l'explication technique derrière… c'est con, ça fait tache.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 22 décembre 2017 à 11:45. Évalué à 5.
        
        et on choppe
        
        >>> Decimal('100') * Decimal('3') / Decimal('6') == Decimal('50') / Decimal('3') * Decimal('3') False
        
        merde alors; et pourtant je pensais être exacte. Note bien le calcul en flottant ne fait pas mieux, mais ne prétend pas le faire. Au final tu te retrouveras toujours à devoir tester une égalité par rapport à une distance à epsilon, car les cas où tu tombent juste seront uniquement tes cas tests et le jour où tu fous le machin en prod tu vas tout péter.
        
        Plutôt que de réclamer un passage à Decimal par défaut, un changement de l'opérateur == ou un gros warning me semble plus pertinent.
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 11:58. Évalué à -2.
        
        merde alors
        
        Ca, tu peux le dire :)
        
        Note bien le calcul en flottant ne fait pas mieux
        
        Oh ça je m'en doute bien.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 22 décembre 2017 à 13:26. Évalué à 4.
        
        Note bien le calcul en flottant ne fait pas mieux
        
        Oh ça je m'en doute bien.
        
        oups pardon j'ai eu un soucis de version de python ;)
        
        100*3/6==50.0/3*3 True
        
        donc le système flottant fait mieux :P
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 12:02. Évalué à -4.
        
        Et tu prends +1 avec une magnifique démonstration que 300/6 != 50/9
        
        Les mecs, vous êtes risibles.
        
        Mais une fois corrigé, en Perl, ça marche. Donc de Decimal passons à Rationnal par défaut, oui, pourquoi pas (je l'ai aussi dit 500x mais oublions).
        
        Mais de toutes façons on sort du CE2 et des soustractions (sujet du journal, vous divergez).
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par fearan le 22 décembre 2017 à 12:30. Évalué à 5.
        
        les division c'est (ou c'était CE2) (http://laclassebleue.fr/ce2-calcul-la-division-posee/), par ailleurs il faut apprendre à lire 300/6 != 50/3*3, mais là c'est du CP; j'aurais pu me contenter d'un Decimal(50) == Decimal('50')/ Decimal('3')*Decimal('3')
        
        Ou en gros n'importe quel passage par un nombre non décimal. Si tu veux qu'on affiche n/x*x != n ça fait un peu tâche non ?
        
        Il ne faut pas décorner les boeufs avant d'avoir semé le vent
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par Michaël (site web personnel) le 22 décembre 2017 à 13:06. Évalué à 6.
        
        Mais de toutes façons on sort du CE2 et des soustractions (sujet du journal, vous divergez).
        
        En fait ce qui rendrait la discussion potentiellement intéressante ce serait que tu prennes un peu de hauteur et essaie d'organiser les changements qu'il serait nécessaire de faire pour que Python puisse sortir le résultat attendu du calcul de CE2 dont tu parles puis peser les avantages et les inconvénients de ces changements. Ce serait très intéressant et il y a plein de points très différents à aborder, comme par exemple les modifications à faire dans la syntaxe du langage, dans la représentation mémoire des objets, dans l'écriture de bindings avec le C++ (un des points forts de Python est de faciliter au maximum cette écriture). Il pourrait il y avoir plein d'échanges fructueux, de problèmes à résoudre, une discussion stimulante. Mais tout ce qui tu nous donnes c'est du “vous n'êtes pas de mon avis, mon avis est bon, donc vous êtes…” Quel dommage!
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 11:06. Évalué à -4.
        
        Avoir du code qui va péter parce qu'on aura silencieusement modifié un type d'une variable…
        
        Si tu lis la feuille de route de GvR, ils y ont pensé. Ils ont une certaine expérience en matière d'incompatibilité.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 18:25. Évalué à -5.
        
        apprendre ces choses à des élèves ingénieurs est mon métier
        
        Ça y'a pas de doute t'es bien un prof 😂
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 18:28. Évalué à -3.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 19:02. Évalué à -7.
        
        Bah le système français à cursus séparé ingé/fac n'aide pas. Ça produit des gens qui sont d'excellents techniciens mais qui manquent franchement de recul pour appréhender de manière critique les processus de production du savoir et remettre en question les savoirs eux-mêmes. Ça a toujours été le cas et ça mène à ce que j'appelle le 《 singe savant 》. Malheureusement la fac s'aligne de plus en plus sur ce modèle, pour mimer ce qui est supposé être la filière 《 d'excellence 》.
        
        Au bout de la chaîne on aboutit effectivement au fameux 《 c'est comme ça qu'on fait et qu'on a toujours fait, pourquoi changer ? 》
        
        J'ai suivi une telle formation, tout ce qu'il y a de plus classique, mais après ça j'ai eu un parcours un peu plus chaotique. Avoir accès à d'autres manières de penser, voir ces certitudes bousculées par la force des choses, ça aide à relativiser et à mieux accepter les remises en questions. Peut-être est-ce aussi ton cas ?
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 19:17. Évalué à 4.
        
        Ça produit des gens qui sont d'excellents techniciens mais qui manquent franchement de recul pour appréhender de manière critique les processus de production du savoir et remettre en question les savoirs eux-mêmes.
        
        Mais c'est magnifique de bêtise et de préjugé ça ! Heureusement qu'on a ici quelques (2 ?) génies incompris pour faire progresser la science et remettre à leur place des "singes savants" comme moi.
        
        J'aurai tout tenté pour partager un peu de ce que je sais. Tant pis.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 19:41. Évalué à -6.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 19:47. Évalué à 5.
        
        Ce que j'ai dit sur toi c'est que tu ne connais pas les concepts mathématiques de base de l'analyse numérique alors que tu prétends que la communauté scientifique n'a pas assez progressé à ton goût sur un sujet qui concerne………. l'analyse numérique !!!!
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 20:20. Évalué à -4. Dernière modification le 21 décembre 2017 à 20:21.
        
        alors que tu prétends que la communauté scientifique n'a pas assez progressé à ton goût
        
        Dis-moi où j'ai dis ça simplement en revendiquant haut et fort qu'un langage comme Python devrait être capable par défaut d'effectuer 2 - 1.8 - 0.2 sans erreur de calcul. Je n'ai jamais rien dit d'autre dans mes posts.
        
        Tu penses depuis le début que je veux tout représenter parfaitement. Je n'ai jamais parlé de ça. J'ai parlé de maths de CE2. J'ai dis que la moindre des choses, c'est qu'un langage comme Python ne se vautre pas sur des maths de CE2.
        
        Pour cela, il suffirait d'activer Decimal par défaut lors de la déclaration de litéraux par exemple. C'est tout. Pour ma part je suis toujours resté sur le problème posé par le titre de ce journal :
        
        >>> 2 - 1.8 - 0.2 -5.551115123125783e-1
        
        C'est moche, ça fait tache.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 21:17. Évalué à 6.
        
        Ca c'est une erreur de copier/coller
        
        >>> 2 - 1.8 - 0.2 -5.551115123125783e-1
        
        Ca c'est le vrai résultat
        
        >>> 2 - 1.8 - 0.2 -5.551115123125783e-17
        
        Donc à la 17 ème décimale près et non à la 1ère décimale comme tu l'affirmes encore après 100 posts.
        
        Ce truc ne choque que ceux qui ne comprennent pas comment calcule un ordinateur. Mais on s'en fout puisque le programmeur python n'est pas un élève de CE2 et donc il n'a pas besoin de comprendre ça. A l'élève de CE2, par contre, on lui offre une calculatrice qui fait la même erreur mais qui, à l'affichage, arrondit au décimal le plus proche. Quand il arrive au CM1 il fait ses premières fractions et là il s'interroge pourquoi 2/3 se termine par un 7 alors qu'il n'y a que des 6 avant…puis il se dit que l'exactitude sur une calculatrice est une illusion.
        
        1/10 a l'air d'avoir un statut particulier dans ta tête non ? Il y a une raison psychologique derrière ? Le fait que le calcul soit simple et que tu puisses détecter des erreurs à 17ème décimale alors que d'habitude tu ne les vois pas peut-être ?
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 22:11. Évalué à -5.
        
        Donc à la 17 ème décimale près et non à la 1ère décimale comme tu l'affirmes encore après 100 posts.
        
        Faut être précis avec toi, mais tu as raison. IEEE-754 se vautre dans la représentation d'un nombre à 1 décimale : 0.1 par exemple. Mais 17 décimales, toi qui aimes la précision, ça devrait te frustrer non ? Je propose (depuis le début) Decimal qui non seulement ne ferait pas d'erreur sur 0.1, mais qui sur 1/3 tape dans les 28 décimales sans erreur. Ou mieux, Rationnal qui permet de ne pas approximer 1/3.
        
        Tu préfères pas cette exactitude ? Moi si. Et les anneaux aussi je crois.
        
        Ce truc ne choque que ceux qui ne comprennent pas comment calcule un ordinateur.
        
        Et toi ce que tu ne veux pas comprendre, c'est qu'un ordinateur c'est le langage (disons le compilateur) (disons le langage machine… bon je te fais pas le détail) qui décide comment il calcule. Il n'est écrit nulle part que pour représenter "un chiffre à virgules" il faille absolument et uniquement utiliser IEEE-754. Faire une erreur de soustraction de CE2 je trouve ça ridicule. Donc je propose simplement qu'il change son mode de calcul dans le cadre d'un langage généraliste comme Python.
        
        Ca permettra d'éviter des erreurs sur 2.0 - 1.8 - 0.2 (exemple au hasard bien sûr)
        
        on lui offre une calculatrice
        
        Ou Perl, ou l'une des prochaines versions de Python (j'insiste, parce que t'as l'air de continuer à affirmer que mon idée est une idée à la con)
        
        et là il s'interroge pourquoi 2/3 se termine par un 7
        
        Pas si il utilise Perl. Ou peut-être une prochaine version de Python (Decimal ou Rationnal ? A voir). Il sera content de voir que utiliser un langage moderne permet des choses sympa.
        
        puis il se dit que l'exactitude sur une calculatrice est une illusion.
        
        L'exactitude dans tous les cas, oui c'est une illusion, tu m'as déjà expliqué que des scientifiques super intelligents (bcp plus que moi en tous cas) avaient démontré qu'on n'arriverait pas à tout représenter dans une calculatrice (ni dans un float d'ailleurs). Mais dans le cas de 2 - 1.8 - 0.2, au moins, la calculatrice elle se trompe pas (les même scientifiques sont formels). Tu trouves pas que c'est un peu con que Python se trompe sur cette soustraction alors que la calculatrice se trompe pas ?
        Ah pardon, la calculatrice soustrait, alors que Python approxime à … merde je retrouve plus la formule.
        
        Bref, je trouve que ça fait tache.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par snowball (site web personnel) le 21 décembre 2017 à 23:11. Évalué à 0.
        
        Mais 17 décimales, toi qui aimes la précision, ça devrait te frustrer non ?
        
        Je n'ai pas besoin d'une telle précision. Donc non.
        
        Tu préfères pas cette exactitude ? Moi si…. mais qui sur 1/3 tape dans les 28 décimales….
        
        Tu n'as pas d'exactitude puisque 1/3 avec 28 décimales c'est une approximation et pas de l'exactitude. Tu te contredis en moins de 50 mots.
        
        toi ce que tu ne veux pas comprendre, c'est qu'un ordinateur c'est le langage qui décide comment il calcule.
        
        Le programme soumet des calculs à un proco et fait avec ce que peut faire le proco. Au final, tu es totalement tributaire des possibilités du proco. C'est le processeur qui évalue in fine. Tes additions, multiplications etc font toutes appel à ses fonctions internes et s'appuient sur IEEE754, désolé de te décevoir.
        
        [et là il s'interroge pourquoi 2/3 se termine par un 7] Pas si il utilise Perl.
        
        Bah zut ! Si Perl n'affiche pas un 7 à la fin c'est qu'il est bon à mettre à la poubelle puisque s'il affiche 0.6666666666 au lieu de 0.6666666667 alors il ne donne pas la meilleure approximation décimale. Fâcheux ça.
        
        au moins, la calculatrice elle se trompe pas
        
        La calculatrice se trompe plus de 99% du temps comme Decimal, comme Float.
        Dans certains cas exceptionnels (liés au format BCD) ça peut lui arriver d'afficher une valeur exacte, comme Decimal, comme Float.
        
        Aucun de ces systèmes ne peut faire les 4 opérations de manière exacte ne serait-ce que sur les décimaux de [0;1]. Pas besoin d'être un scientifique extraordinaire. Ca s'explique par exemple très bien à des jeunes TS.
        
        Bref, je trouve que ça fait tache.
        
        Ce qui fait tâche c'est davantage de croire qu'une bonne approximation de 2/3 c'est 0.6666666666 et non 0.6666666667. Mais ça montre bien ce que je dis, tu n'as pas de conception numérique suffisamment avancée pour dire des choses sur un sujet aussi technique. C'est juste un fait, pas une critique. Ce qui est incroyable par contre c'est ton aveuglement sur ton incapacité à comprendre le sujet.
        
        Ou Perl, ou l'une des prochaines versions de Python (j'insiste, parce que t'as l'air de continuer à affirmer que mon idée est une idée à la con)
        
        Ce qu'ils font c'est ce que fait Ada depuis 1983 : grosso modo fournir un service de virgule fixe standard. Qu'ils le fassent ou non ne change absolument rien à ce que je dis. Mais comme tu ne comprends pas à quoi sert la virgule fixe par rapport à la virgule flottante, tu crois qu'ils vont faire du calcul "exact" (alors qu'évidement ça ne se produira que dans des cas dont la probabilité est proche de 0). Explication dans ce ps avec la calculatrice:
        
        PS
        "La calculatrice (avec une mantisse de 13 chiffres disons) se trompe plus de 99% du temps" signifie que si tu fais une opération élémentaire aléatoire entre deux décimaux aléatoires sur une calculatrice, la proba que le résultat soit correct est de moins de 1% (une piste de démonstration: la proba que le 13 chiffre après la virgule soit nul est de 1/10. Du coup la proba que les deux opérandes aient simultanément un 13 ème chiffre nul après la virgule est de 1%. Or c'est dans ce 1% qu'une addition/soustraction tombe juste). Je passe les opérations pour lesquelles c'est encore plus rare que ça donne un résultat exact qui font encore plus chuter tes illusions sur la calculatrice.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 07:24. Évalué à -3.
        
        Tes additions, multiplications etc font toutes appel à ses fonctions internes et s'appuient sur IEEE754, désolé de te décevoir.
        
        Là tu ne m'as pas du tout déçu. J'ai compris maintenant pourquoi ce thread ne s'arrêtera jamais.
        
        J'espère que tes étudiants ne tomberont pas sur cette phrase.
        
        Ca fait tache…
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 20:30. Évalué à -7.
        
        Mais c'est magnifique de bêtise et de préjugé ça !
        
        Oulà si tu savais comme j'aimerais qu'il en soit autrement !
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 19:22. Évalué à -7.
        
        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.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 21 décembre 2017 à 23:09. Évalué à -4.
        
        C'est plutôt très pragmatique ce que tu proposes.
        
        Après quelques recherches je suis tombé sur la PEP3141 et le concept de numerical tower (voir wikipedia anglaise) avec le lisp scheme &co (est-ce qu'il en a été fait mention? Je n'ai pas lu tous les commentaires)
        
        Y'a plus qu'à faire une PEP ! S'il n'en existe pas déjà une 😓 ce serait assez simple à coder au moins comme preuve de concept. J'ai la norme scheme sous les yeux et il est explicitement précisé que si la plupart du temps on implémente les rational comme les real ça n'a rien de systématique.
        
        http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2.1
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 11:01. Évalué à -2.
        
        Génial, merci :)
        
        Une brique de plus : à la base c'est pas con, c'est même la tendance actuelle.
        
        Une petite pensée pour les 9/10e des posts tentant de me convaincre de l'inverse, voire que c'est carrément pas possible.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Puisque tout le monde est sûr de détenir la vérité...
        
        Posté par .Nicolas. le 22 décembre 2017 à 14:11. Évalué à 0.
        
        Et pour enfoncer le clou, il existe des opérations qui ont cette fâcheuse manie de faire diverger l'erreur numérique. C'est typiquement le cas de la soustraction de deux float de valeur quasi-identique (parce ton erreur va être de 1e-17/(résultat attendu) et que le résultat attendu va être 0 ou une valeur très proche). Ces opérations on les apprend lorsqu'on étudie les simulations numériques, par exemple. Parce que ça peu très vite mettre par terre l'exploitation des résultats.
        
        Tout ça pour dire que le cas du journal est un exemple classique qu'on montre aux étudiants pour leur faire bien comprendre les limites du float. C'est connu et ça ne fait pas vraiment débat en réalité.
# Pourquoi calculer en virgule flottante?

Posté par Michaël (site web personnel) le 21 décembre 2017 à 11:36. Évalué à 10. Dernière modification le 21 décembre 2017 à 11:36.
On a de temps en temps des discussions ici sur le calcul en virgule flottante et les désagrément qu'il peut causer à ceux qui en découvrent les limitations, mais on ne parle presque jamais de ce à quoi sert le calcul en virgule flottante… c'est-à-dire de la raison pour laquelle on a développé cet outil! Réparons cet oubli.

Quand on calcule, disons avec des nombres réels, il y a très peu de nombres que l'on sait représenter et très peu d'opérations que l'on sait mener exactement. Les nombres que l'on sait bien représenter sont les nombres rationnels (avec un numérateur et un dénominateur pas trop gros) et les opérations que l'on sait bien mener sont l'addition, la soustraction, la multiplication, la division et la comparaison.

Si on veut faire exactement ces cinq opérations les nombres rationnels sont le plus grand sous-ensemble (sous-anneau pour être précis) des nombres réels qui marche. Si par exemple j'ajoute un nombre irrationnel comme la racine carrée de 2 par exemple, le calcul symbolique exact reste possible mais la comparaison devient un problème difficile: d'une part il devient coûteux en temps et en espace de déterminer si un nombre est plus grand qu'un autre et tester l'égalité devient aussi un problème – et si on fait abstraction de quelques cas faciles, ces problèmes sont largement irrésolus si on veut travailler avec plusieurs irrationnels simultanément. Ainsi, pour calculer exactement, si on s'en tient aux opérations arithmétique de base, il faut utiliser les nombres rationnels.

Mais les opérations arithmétiques de base ne recoupent pas tout ce qu'on fait en calcul scientifique.

Par exemple la fonction exponentielle, et partant la fonction logarithme et toutes les fonctions trigonométriques prennent des valeur irrationnelles aux point rationnels de la droite réelle (à quelques exceptions notoires, comme exp 0 = 1). Ainsi par exemple exp 2 n'est pas rationnel, comment calculer avec ce nombre? Il y a deux approches, et seulement deux car on ne sait pas faire grand chose d'autre: soit on calcule de façon symbolique soit en prenant une valeur approchée. Le calcul symbolique ne marche que dans les cas les plus simples, si je construis deux expression complexes avec des nombres entiers et des nombres irrationnels obtenus par divers moyens, on ne peut pas les comparer facilement par exemple, et toutes les opérations plus complexes sont impraticables. Le calcul d'une valeur approchée lui est parfois possible. (Mais pas toujours: parfois on sait démontrer l'existence d'un nombre sans que cela en fournisse une méthode de calcul approché, en mathématiques il y a aussi des “constantes universelles”.)

Mais l'exponentielle n'est qu'un exemple! Il existe beaucoup d'autres fonctions classiques comme les fonctions de Bessel, les fonctions gamma d'Euler, par exemple, dont on ne sait pas calculer les valeurs exactement. Si on pratique le calcul intégral, qu'on travaille avec des limites de suites ou de séries, qu'on recherche les zéros d'une fonction, ou encore qu'on recherche la solution d'une équation différentielle, on se retrouve avec autant d'exemples où le calcul symbolique (et a fortiori le calcul sur les nombres rationnels) est impossible à utiliser. C'est précisément à ce genre de calculs que servent les nombres en virgule flottante, et fournissent une très bonne solution: puisque par nature le calcul exact n'est pas possible, autant privilégier la vitesse de calcul. De plus le calcul en virgule flottante donne un cadre où l'on peut utiliser diverses techniques pour maîtriser l'erreur commise – c'est bien-sûr un sujet de recherche en soi! Un exemple simple de ces techniques est la méthode de sommation de Kahan. Pour résumer, le problème de physique les plus complexe qu'on sache résoudre exactement avec les moyens de l'arithmétique exacte est celui de la chute d'un corps soumis à une force (son poids) et pour tout le reste on doit utiliser des techniques de calcul approché. En pratique on utilise une approche mixte: c'est très difficile de construire une bonne approximation pour une fonction arbitraire, donc en pratique on utilise le calcul symbolique pour essayer de construire une méthode de calcul qui tire parti de calculs numériques bien compris!

Pour en revenir à la découverte du journal:
```
>>> 2 - 1.8 - 0.2
-5.551115123125783e-1
```
C'est la démonstration que Python n'utilise pas l'arithmétique exacte pour mener ce calcul et si ce n'est pas le comportement escompté il faut se documenter et rechercher la méthode appropriée!
- [^] # Re: Pourquoi calculer en virgule flottante?
  
  Posté par gUI (Mastodon) le 21 décembre 2017 à 12:32. Évalué à -6.
  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.
  - [^] # Re: Pourquoi calculer en virgule flottante?
    
    Posté par fearan le 21 décembre 2017 à 12:47. Évalué à 5.
    
    tien, cadeau, sur la doc de base
    
    https://docs.python.org/fr/3.6/library/stdtypes.html
    
    Il existe trois types numériques distincts: integers (entiers), floating point numbers (nombres flottants) et complex numbers (nombres complexes). En outre, les booléens sont un sous-type des entiers. Les entiers ont une précision illimitée. Les nombres à virgule flottante sont généralement implémentés en utilisant des double en C ; des informations sur la précision et la représentation interne des nombres à virgule flottante pour la machine sur laquelle le programme est en cours d’exécution est disponible dans sys.float_info.
    
    Faut même pas aller chercher loin. Si tu commence à vouloir coder sans même prendre connaissance de la base tu va au devant de gros ennuis.
    
    Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  - [^] # Re: Pourquoi calculer en virgule flottante?
    
    Posté par Marotte ⛧ le 21 décembre 2017 à 12:54. Évalué à 7.
    
    Je crois que c’est Faya qui a fait le commentaire le plus pertinent : Perl6 fonctionne comme tu penses qu’un langage généraliste devrait fonctionner au 21e siècle : il utilise des fractions par défaut. Il te faut donc abandonner Python pour te mettre à Perl 6, tu ne peux pas continuer à utiliser un langage pré-historique qui utilise des floats pour tout calcul sur des décimaux quand même ?!
    
    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
    
    Bah oui. OSEF des soustractions à 1 chiffre après la virgule. On privilégie ce qui est utile.
    
    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
    
    Python et beaucoup d’autres… Je ne savais pas pour Perl6, l’avenir nous dira si les autres langages finissent par adopter ce comportement ~~déviant~~ original.
    - [^] # Re: Pourquoi calculer en virgule flottante?
      
      Posté par gUI (Mastodon) le 22 décembre 2017 à 07:56. Évalué à 1.
      
      Je ne savais pas pour Perl6, l’avenir nous dira si les autres langages finissent par adopter ce comportement ~~déviant~~ original.
      
      En tous cas, côté Python, ils y ont pensé.
      
      Même si c'est en sommeil (divesres raisons, la perfo en tête bien évidemment), je préfère déduire de ce post que mon idée n'est finalement pas si con que ça, et m'en tenir là. Mais comme c'est moi qui juge avec l'intelligence que j'ai… pitié, laissez-moi dans ma crédulité.
      
      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
  - [^] # Re: Pourquoi calculer en virgule flottante?
    
    Posté par .Nicolas. le 21 décembre 2017 à 13:37. Évalué à -6.
    
    Mettre 《 performance 》 et 《 Python 》 dans la même phrase. Moi je dis y'a des claques qui se perdent. Ceux qui ont sorti cet argument, ils devraient être jetés en pâture aux crocodiles après avoir réécrit Firefox en assembleur, leur nom devrait être maudit pour 100,0 siècles, et tous les membres de leur famille devrait être écartelés en place publique pour empêcher toute prolifération de la vermine.
    
    Le langage le plus lent de la création. Plus lent que ça tu pars à reculons.
    - [^] # Re: Pourquoi calculer en virgule flottante?
      
      Posté par gUI (Mastodon) le 21 décembre 2017 à 13:55. Évalué à 1.
      
      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.
    - [^] # Re: Pourquoi calculer en virgule flottante?
      
      Posté par Marotte ⛧ le 21 décembre 2017 à 22:35. Évalué à 5. Dernière modification le 21 décembre 2017 à 22:36.
      
      Les claques elles devraient aller droit dans la chetron de celui qui dénigre un langage sans aucun argument, sans aucun lien pour étayer son assertion. Le premier lien que je google me trouve, date certes de 2010, et montre de bonnes performances pour Python par rapport à PHP ou Perl. Ruby mieux mais pas chut pas troller.
      
      Tu voulais peut-être faire remarquer le simple fait qu’un langage interprété se fait enterrer par n’importe quel code issu d’une compilation ? Mais dans tous les cas, vraiment, je te dis ça pour toi et ton karma, il va falloir que tu argumentes un minimum quand tu sors des propos pareils.
      
      Pour les parties d’un programme réclamant réellement du CPU, comme de gros calculs de brute en virgule flottante sur 256 bits, Python, et en particulier Cython permet, en quelque sorte, de « compiler du Python ». Donc… bon… Tu as perdu une occasion de te taire, à mon humble avis.
      
      Pour 99,9% du code sur cette planète (chiffre de mon doigt mouillé), qu’une boucle s’exécute en 1ms au lieu de 10ms n’est absolument pas un critère qui pèse dans le choix du langage…
      
      Le langage le plus lent de la création. Plus lent que ça tu pars à reculons.
      
      J’aime bien la formule ! C’est le seul truc agréable de ton commentaire.
      - [^] # Re: Pourquoi calculer en virgule flottante?
        
        Posté par gUI (Mastodon) le 21 décembre 2017 à 22:40. Évalué à -4.
        
        Pour 99,9% du code sur cette planète (chiffre de mon doigt mouillé), qu’une boucle s’exécute en 1ms au lieu de 10ms n’est absolument pas un critère qui pèse dans le choix du langage…
        
        Merci c'est un bon argument pour justifier que Python pourrait utiliser Decimal au lieu de float par défaut pour les litéraux :)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Pourquoi calculer en virgule flottante?
        
        Posté par Marotte ⛧ le 21 décembre 2017 à 23:21. Évalué à 5. Dernière modification le 21 décembre 2017 à 23:23.
        
        Merci c'est un bon argument pour justifier que Python pourrait utiliser Decimal au lieu de float par défaut pour les litéraux :)
        
        Et bien justement, bien au contraire j’ai envie de dire… Pour les quelques pourcent du code qui nécessitent de la performance il s’agit très souvent de calcul « littéral » (puisque tu emploies ce terme…), précisément !
        
        Donc si Python utilisait Fraction() ou Decimal() par défaut il faudrait sortir cython pour faire le moindre truc un peu calculatoire… Je crois que tu connais maintenant l’avis des utilisateurs du site sur le sujet !
        
        Le code qui ne nécessite pas de bourriner, c’est notamment tout ce qui est interaction humain-machine. De manière générale, tout ce qui ne nécessite pas d’avoir des perfs de ouf doit plutôt privilégier la maintenabilité du code et son exploitabilité, ou que sais-je encore.
        
        Enfin bon. Tu lâcheras rien je vois ça :) Maintenant, sachant que Perl6 répond à ton besoin tu devrais t’y mettre ! … À moins que… en fait, même toi… n’est absolument pas dérangé par les erreurs d’arrondi dues à l’utilisation des floats, et que c’est pas ce qui te fait choisir le langage que tu utilises ;)
        
        [^] # Re: Pourquoi calculer en virgule flottante?
        
        Posté par Marotte ⛧ le 22 décembre 2017 à 01:10. Évalué à 3.
        
        Donc si Python utilisait Fraction() ou Decimal() par défaut il faudrait sortir cython pour faire le moindre truc un peu calculatoire…
        
        Il peut-être juste charger et utiliser un objet Float() c’est vrai mais ça reste pénible…
        
        [^] # Re: Pourquoi calculer en virgule flottante?
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 10:51. Évalué à -1.
        
        Maintenant, sachant que Perl6 répond à ton besoin tu devrais t’y mettre
        
        Je reste simplement factuel. Le journal (pour y revenir) parle d'une soustraction dans Python. Je dis ça fait tache, je me fais incendier. J'ai mis 3 jours, mais je pense qu'on peut le dire clairement : oui, ça fait tache (source : les créateurs de Python eux-même)
        
        CQFD.
        
        Mes goûts perso n'ont rien à voir là dedans. Pas facile de rester factuel au post initial du journal. Une simple soustraction en Python et on en est venu à me parler de théorie analytique, d'ordinateurs quantiques, de la pollution humaine, de la granularité de l'espace temps…
        
        Python, une soustraction, je n'ai pas démordu de ça.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Pourquoi calculer en virgule flottante?
        
        Posté par Marotte ⛧ le 22 décembre 2017 à 12:40. Évalué à 2.
        
        Je reste simplement factuel. Le journal (pour y revenir) parle d'une soustraction dans Python. Je dis ça fait tache, je me fais incendier. J'ai mis 3 jours, mais je pense qu'on peut le dire clairement : oui, ça fait tache (source : les créateurs de Python eux-même)
        
        Tu peux me dire où Guido (ou un autre développeur de Python) a dit que ça « faisait tâche » ?
        
        C’est là où tu vas trop loin… Tu ne te fais pas incendier parce que tu juges que Python 3 devrait utiliser du décimal/fractionnel par défaut, qui est un avis qu’on a le droit d’avoir et d’exprimer, tu te fais incendier parce que tu dis que float par défaut (donc obtenir 5.511…e-17 au lieu de 0) n’est pas acceptable, incompréhensible à notre époque, une « tâche », etc… et ça c’est proprement ridicule.
        
        Une simple soustraction en Python et on en est venu à me parler de théorie analytique, d'ordinateurs quantiques, de la pollution humaine, de la granularité de l'espace temps…
        
        Bah oui… encore une fois : Python n’est pas fait pour calculer des soustractions simples, il est conçu pour résoudre des problèmes scientifiques réels. C’est ça que tu ne peux/veux pas comprendre/accepter.
        
        Maintenant moi j’arrête là. Reste avec ta vision des choses si ça te fait plaisir…
        
        [^] # Re: Pourquoi calculer en virgule flottante?
        
        Posté par BAud (site web personnel) le 27 décembre 2017 à 00:01. Évalué à 1.
        
        Maintenant moi j’arrête là. Reste avec ta vision des choses si ça te fait plaisir…
        
        bin moi sa vision me semble normale : l'ordi est pour répondre à nos besoins (que ce soit en python)
        une vision scientifique évolue justement par ses contradictions : une théorie reste vraie tant qu'elle n'a pas éprouvé de contradiction, un théorème en maths n'est vrai que tant qu'il n'a pas été prouvé. Mpi je préfère les maths.
        
        à voir.
        
        [^] # Re: Pourquoi calculer en virgule flottante?
        
        Posté par Marotte ⛧ le 27 décembre 2017 à 11:53. Évalué à 6.
        
        une théorie reste vraie tant qu'elle n'a pas éprouvé de contradiction
        
        Ah bon ? Je dois mal comprendre ta phrase… Je peux donc prétendre que Dieu existe, à toi d’apporter la preuve du contraire sinon ma théorie est vraie ?
        
        un théorème en maths n'est vrai que tant qu'il n'a pas été prouvé
        
        Encore pas compris là. Un théorème peut être vrai ou faux, il est surtout démontrable. On retient plutôt les théorèmes vrais (donc démontrés) en général.
        
        [^] # Re: Pourquoi calculer en virgule flottante?
        
        Posté par Marotte ⛧ le 27 décembre 2017 à 11:54. Évalué à 3.
        
        une théorie reste vraie tant qu'elle n'a pas éprouvé de contradiction
        
        Ah bon ? Je dois mal comprendre ta phrase… Je peux donc prétendre que Dieu existe, à toi d’apporter la preuve du contraire sinon ma théorie est vraie ?
        
        un théorème en maths n'est vrai que tant qu'il n'a pas été prouvé
        
        Encore pas compris là. Un théorème peut être vrai ou faux, il est surtout démontrable. On retient plutôt les théorèmes démontrés être vrais en général…
  - [^] # Re: Pourquoi calculer en virgule flottante?
    
    Posté par snowball (site web personnel) le 21 décembre 2017 à 13:40. Évalué à 5.
    
    Tu ne résumes rien, puisque tu tords les réponses qu'on donne à tes questions de débutant qui ne comprend rien pour en faire des idioties, et ce, depuis une centaine de posts.
    
    Une calculatrice calcule quasiment tout le temps de faux, mais quand tu t'en aperçois (c'est à dire sur des décimaux où c'est plus visible) tu cries au scandale.
    
    PS
    Quand je dis "Une calculatrice calcule quasiment tout le temps de faux" je peux préciser:
    
    La probabilité qu'une suite de moins de 4 opérations sur une calculatrice concernant des petits décimaux gentils (disons compris entre -10 et 10) soit fausse à l'affichage est supérieure à 99%. Ca se démontre ça si tu veux.
    
    Et on peut démontrer que c'est aussi le cas pour n'importe quel autre système de calcul sur une machine de Turing.
  - [^] # Re: Pourquoi calculer en virgule flottante?
    
    Posté par Michaël (site web personnel) le 21 décembre 2017 à 14:02. Évalué à 7.
    
    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
    
    Si tu penses qu'il serait plus judicieux que Python utilise de l'arithmétique exacte tant qu'il le peut pour effectuer les calculs, c'est certainement un point de vue défendable, mais je ne vois pas dans tes commentaires ce qui ressemblerait à un effort pour construire un argumentaire là-dessus et à comparer avec les avantages et les inconvénients d'un changement par rapport au status quo.
    - [^] # Re: Pourquoi calculer en virgule flottante?
      
      Posté par snowball (site web personnel) le 21 décembre 2017 à 18:18. Évalué à 4.
      
      Tout à fait.
      Il n'en est pas à ce stade de la réflexion car il lui manque les concepts fondamentaux de l'analyse numérique à commencer par "quels sont les différents ensembles de nombres et leurs structures algébriques ?" et "comment représenter les nombres en machine ?".
# decimal32 est la solution à tous^Wce problème spécifique

Posté par 2PetitsVerres le 21 décembre 2017 à 14:16. Évalué à 8.

Pour rajouter une pièce dans la machine, je tiens à souligner que la dernière révision du standard IEEE754 (celle de 2008) introduit trois représentations de nombres flottants décimaux (decimalN avec N={32,64,128})

Du coup, si python utilisait cette représentation et tournait sur une machine qui sait les utiliser (ça existe ça ? Quelqu'un a déjà vu des instructions pour ça ? En plus c'est le bazar, la "spécification" laisse la place pour au moins deux représentations au niveau des bits différentes), le problème n’apparaîtrait pas dans "2 - 1.8 - 0.2".

Alors attention, je dis bien que le problème n’apparaîtrait pas dans ce cas précis, mais ça n'empêcherait pas le problème d'exister, dans avec d'autres nombres, mais c'est moins visible pour l'utilisateur.

Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
- [^] # Re: decimal32 est la solution à tous^Wce problème spécifique
  
  Posté par Marotte ⛧ le 21 décembre 2017 à 23:26. Évalué à 5. Dernière modification le 21 décembre 2017 à 23:26.
  
  ça n'empêcherait pas le problème d'exister, dans avec d'autres nombres, mais c'est moins visible pour l'utilisateur.
  
  C’est bien là un des gros avantages du calcul en virgule flottante : c’est « bête », du coup les erreurs sont (pré)visibles.
# Petit résumé et tests dans la réalité

Posté par snowball (site web personnel) le 22 décembre 2017 à 15:47. Évalué à 4.
De ce que j'ai compris de tous ces posts:
```
Decimal('10') * Decimal('1')/Decimal('10') !=Decimal ('1') // ça, pour gUI, ça ferait tâche
Decimal('3' ) * Decimal('1')/Decimal('3')  !=Decimal ('1') // ça, pour gUi ça ne fait pas tâche
```
- C'est totalement psychologique et pas rationnel (sans jeu de mot) pour un sou puisqu'une petite analyse qui prend 30s montre que le cas de la division par une puissance de 10 ne se produit que très rarement. Pour preuve le raisonnement élémentaire suivant:
- les divisions par des puissances de 10 lorsqu'on manipule des mantisses de 13 chiffres, ça a une probabilité d'occurrence d'environ $1/10^{12}$ soit 20 000 fois inférieure à celle de gagner au loto !!! Mais il s'en fout. Il est d'ailleurs prêt à accepter que python multiplie par au moins 10 le temps de calcul par défaut sur des nombres et gaspille environ 200% d'espace mémoire (un numérateur, un dénominateur) de stockage pour avoir une illusion d'exactitude sur certains résultats (ne concernant qu'une occurrence sur plus de vingt mille milliards possibles).
- gUI est persuadé que python va s'y mettre alors qu'en fait y a juste 4 personnes sur un groupe nommé python.ideas qui se demandent si ça aurait un intérêt (cf le lien qu'il donne). Et visiblement, ceux qui en discutent sur ce forum ne sont pas très enthousiastes (et d'ailleurs il y a très peu de réflexions déposées).
Maintenant passons aux expériences dans la réalité avec un tout petit bench

En python
```
i=0.0
while i < 100.0:
  i += 0.000375 //utilisation du type float.
```
```
time python test.py
real 0m0,063s
user 0m0,035s
sys  0m0,000s
```
Maintenant en perl6 (attention, ça pique !)
```
loop (my $i=0.0; $i < 100.0; $i = $i + 0.000375) {}
```
```
time perl6 test.pl
real 0m10,449s
user 0m8,648s
sys  0m0,012s
```
Soit une performance divisée par 175 par rapport à Python !!! Rien que ça :)
L'avantage d'avoir manipulé des décimaux (ou des rationnels, on ne sait pas), c'était quoi ? Le choix de passer par ce type rationnel était totalement absurde, et en plus il a été fait par défaut.

Beaucoup plus intéressant encore: en perl5, ça donne quoi actuellement ?
```
for (my $i=0.0; $i < 100.0; $i = $i + 0.000375) {}
```
```
time perl test.pl
real 0m0,216s
user 0m8,171s
sys  0m0,06s
```
Autrement dit, le passage par défaut en decimal, a objectivement donné une exécution 48 fois plus lente (j'étais pas si loin quand je disais 50).

Tout ça dans quel intérêt au juste ? Absolument aucun.
A ce sujet, le dev qui s'est chargé de ça intervient ici https://stackoverflow.com/questions/46840840/does-perl-6-performance-suffer-by-using-rationals-for-decimal-numbers pour répondre à une interrogation tout à fait fondée et répond, sans bench à l'appui, que "grosso modo" ça n'a que peu d'impact (bah voyons !). Pourtant, toujours sur cette page, le seul retour d'utilisateur est un gars qui explique l'explosion du coût de calcul (rien que pour le module de passage aux strings à l'affichage).

Petite remarque

En Ada avec la virgule fixe (donc sans aucune approximation via une abstraction au dessus de float) le même test donne
```
procedure fix is
  type my_real is delta 0.000_375 range 0.0..100.0;
begin
  for e of my_real loop null; end loop;
end fix;
```
```
real    0m0,002s
user    0m0,007s
sys 0m0,000s
```
Sans appel. Il aurait peut-être été bon que le gars qui s'est occupé du passage au type Rat par défaut chez perl, fasse un petit bench et explique l'intérêt de diviser les perfs par 50 pour éviter de faire "tâche" dans une proportion d'un calcul sur 1000 milliards. Il reste toujours la possibilité d'utiliser perl5 ;)
- [^] # Re: Petit résumé et tests dans la réalité
  
  Posté par snowball (site web personnel) le 22 décembre 2017 à 16:05. Évalué à 4.
  
  PS
  (oui je me réponds à moi-même et je sais que ça se fait pas :) )
  
  Imaginez un peu l'envolée du bench en perl6 si j'avais fait la somme des 1/(1+$i) dans la boucle :) Sachant que s'il essaye de rester exact, il aurait eu un dénominateur de l'ordre de factoriel 1000 ! (quelques centaines de mégaoctets en mémoire quoi)
  - [^] # Re: Petit résumé et tests dans la réalité
    
    Posté par jben le 22 décembre 2017 à 19:17. Évalué à 4. Dernière modification le 22 décembre 2017 à 19:18.
    Imaginez un peu l'envolée du bench en perl6 si j'avais fait la somme des 1/(1+$i) dans la boucle :) Sachant que s'il essaye de rester exact, il aurait eu un dénominateur de l'ordre de factoriel 1000 ! (quelques centaines de mégaoctets en mémoire quoi)
    
    Non :
```
jben@garance ~ $ ipython
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
Type 'copyright', 'credits' or 'license' for more information
IPython 6.1.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import sympy

In [2]: %time sum(sympy.Rational(1,i) for i in range(1,1000))
CPU times: user 212 ms, sys: 0 ns, total: 212 ms
Wall time: 214 ms
Out[2]: 53355784417020119952537879239887266136731803921522374204060897246465114565409520
6460066214578331218198221770137334485231219291918538173884550508784555617173710275921574
8965188479557007846450532179896775486032218896917266500463393547109645547063364509427051
3262722579396248817332458071400971347691033193734596623333937737766140820373673275246317
8595259568858047165701222717711597153394382396137958761316601838461491677404775571999189
97/7128865274665093053166384155714272920668358861885893040452001991154324087581111499476
4441519138715869117178170195752565129802640676210092514658710043051310726862681432001966
0997486274593718834370501543445252373974529896314567498212823695623282379401106880926231
7708861979540791247754558049326475737829923352751796735248042463638051137034331214781746
850878453485678021888075373249921995672056932029099390891687487672697950931603520000
```
    Notons bien que je ne pense pas que faire les calculs sur des rationnels par defaut soit une bonne idée, je relevais juste une erreur.
    - [^] # Re: Petit résumé et tests dans la réalité
      
      Posté par snowball (site web personnel) le 22 décembre 2017 à 19:25. Évalué à 1.
      
      Oups, oui tu as tout à fait raison. Gros gros bug de ma part :) J'ai honte :)
      
      Par contre, j'ai fait le test avec perl6 et il se vautre (arrêt brutal du programme) simplement en demandant les 47 premiers termes de la suite.
      - [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 20:26. Évalué à 0.
        
        Moi aussi j'ai fait le test en perl6
        
        Le code :
        
        #!/usr/bin/perl6 my $S=0; loop (my $i=2; $i < 47; $i++) { $S += 1/$i; say $S.nude; }
        
        Le résultat : (j'explique entre parenthèse comment lire nude qui donne la représentation interne).
        
        (1 2) => 1/2
        (5 6) => 1/2 + 1/3 = 3/6 + 2/6 = 5/6
        (13 12) => 1/2 + 1/3 + 1/4 = 6/12 + 4/12 + 3/12 = 13/12
        (77 60) => 1/2 + 1/3 + 1/4 + 1/5 = 30/60 + 20/60 + 15/60 + 12/60 = 77/60
        (29 20)
        (223 140)
        (481 280)
        (4609 2520)
        (4861 2520)
        (55991 27720)
        (58301 27720)
        (785633 360360)
        (811373 360360)
        (835397 360360)
        (1715839 720720)
        (29889983 12252240)
        (10190221 4084080)
        (197698279 77597520)
        (40315631 15519504)
        (13684885 5173168)
        (13920029 5173168)
        (325333835 118982864)
        (990874363 356948592)
        (25128807667 8923714800)
        (25472027467 8923714800)
        (232222818803 80313433200)
        (235091155703 80313433200)
        (6897956948587 2329089562800)
        (6975593267347 2329089562800)
        (218572480850557 72201776446800)
        (441657572729039 144403552893600)
        (40548494360749 13127595717600)
        (40934600117149 13127595717600)
        (41309674280509 13127595717600)
        (41674329717109 13127595717600)
        (1555077795250633 485721041551200)
        (1567859927923033 485721041551200)
        (1580314313603833 485721041551200)
        (1592457339642613 485721041551200)
        (65776471966898333 19914562703599200)
        (9464375460249419 2844937529085600)
        (409813082319810617 122332313750680800)
        (4538526983955586987 1345655451257488800)
        (4568430438427975627 1345655451257488800)
        (4597683817803138427 1345655451257488800)
        
        Alors très honnêtement j'ai pas la patience de vérifier, et encore plus honnêtement j'ai pas le niveau pour vérifier facilement. Tu saurais me dire si la valeur finale est exacte ou pas ?
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 20:31. Évalué à 4.
        
        Non tu n'as pas fait le même test.
        Tu t'arrêtes (volontairement) au 46 ème terme. Coquinou :)
        
        Mais dès que tu ajoutes un tout petit rationnel 1/47 (c'est pas demandé la lune d'ajouter 1/47), PAF, CRASH total de perl …au revoir…
        Voilà les dangers: aucun contrôle possible, aucune dynamique possible (ajouter un 47ème c'est une demande de dynamique ridicule).
        
        Me dis pas que tu n'as toujours pas compris hein !
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 20:44. Évalué à 1.
        
        Anéfé, il me manquait une boucle :)
        Et là oui ça devient passionnant !
        
        Le mien ne plante pas. Si je modifie "<48", les 2 dernières lignes :
        
        (4597683817803138427 1345655451257488800)
        No such method 'nude' for invocant of type 'Num
        
        => Il a quitté tout seul rationnal pour choisir un autre type.
        
        Si je remets un bon vieux "say" qui sera compatible avec tous les types, mes 2 dernières lignes sont :
        3.41668724598610475071
        3.43796384173079
        
        => Par contre il a perdu énormément de précision au passage en float, c'était bcp mieux le rationnal (et exact !)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 20:49. Évalué à 1.
        
        https://i.imgur.com/cYk1ub5.png
        et ma version
        https://i.imgur.com/UjEuZOr.png
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 21:00. Évalué à 3.
        
        Je pense que tu es simplement arrivé au bout du type Rat (que tu as imposé explicitement, c'est ça ?). Pour ma part j'impose rien (Rat est en défaut), il a donc switché en float.
        
        Rat a un énormément plus petit range, en échange d'une plus grande précision. Pas de secret, faut payer ! D'où l'idée de rester en plus grande précision tant que c'est possible, puis de switcher sur float quand c'est nécessaire.
        
        C'est ni plus ni moins la méthode que je préconisais (avec Decimal sous Python, ici c'est Rat sous Perl), mais bon… c'est une mauvaise idée, tu l'as montré.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 21:18. Évalué à 2.
        
        Cette idée n'a pas été retenue pour les raisons invoquées par Guido lui même dans le lien que tu as donné. Il a donné les principales absurdités que ça entraînait, d'autres t'ont été données par plusieurs autres intervenants ici à plusieurs reprises.
        
        En fait, la science a fait le tour de ces sujets depuis très longtemps (avant même que (que la technologie informatique n'existe je pense), tout comme Blaise Pascal avait déjà tous les algos et leur complexité avant même la naissance de la première calculatrice: c'est la magie des maths.
        
        Grâce aux maths, nn sait exactement ce qu'on ne peut pas obtenir, on sait à l'avance combien coûte ce qu'on aurait pu désirer, on sait décider pour quels problèmes il faut choisir de la virgule fixe, on sait aussi quelle limite ça a, on l'a déjà implémenté dans les langages standard, on l'a implémenté de manière optimale etc etc. De ce côté là, on n'a plus rien à chercher et on l'a démontré.
        
        En analyse numérique on est allé bien plus loin que ces considérations depuis des années. C'est pour ça que ce que tu as raconté pendant des pages était aussi agaçant (la suffisance (involontaire ?) vis à vis de la communauté scientifique et l'ignorance ça fait un mauvais mélange, surtout le passage où on était limite dans la phase 'génie incompris').
        
        Peace et noyeux joel.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 21:52. Évalué à 2.
        
        Grâce aux maths, nn sait exactement ce qu'on ne peut pas obtenir
        
        Dialogue de sourds :)
        
        Peace et noyeux joel.
        
        Yes !!!
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 22:10. Évalué à 5.
        
        Dialogue de sourds :)
        
        De mon côté, je t'écoute, je prends le temps d'argumenter et j'étaye par des maths (que tu ne lis pas) ou par des bench (ça, heureusement, tu prends, j'ai de la chance).
        
        Il me semble pourtant qu' en faisant des maths hier, je t'avais calculé le facteur 50 de chute des perfs non ? Mais visiblement tu ne voulais pas lire, tout persuadé que si des gars l'avaient poussé dans perl6 c'est que tu avais raison. C'est donc bien ta surdité qui est en cause, pas la mienne. Vu l'énergie que j'ai dû dépenser à argumenter je mérite au moins que tu ne me taxes pas de surdité il me semble.
        
        Dis moi, t'es fâché avec les maths en vrai, c'est ça non ?
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 22:25. Évalué à 0.
        
        Il me semble pourtant qu' en faisant des maths hier, je t'avais calculé le facteur 50 de chute des perfs non ?
        
        T'as confirmé le facteur 50 avec Python3 ?
        
        T'as trouvé ton facteur 50 en Perl ?
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 22:51. Évalué à 3.
        
        T'as confirmé le facteur 50 avec Python3 ?
        
        oui (decimal vs float)
        
        T'as trouvé ton facteur 50 en Perl ?
        
        oui (num vs Rat)
        
        Fais les bench toi même et tu constateras ces ordres de grandeur (qui peuvent varier d'une mesure à l'autre et qu'il faut donc répéter pas mal de fois pour avoir une tendance moyenne)
        
        Mais c'est totalement prévisible vu qu'il n'y a rien de magique: c'est juste des maths quoi. Il me semble avoir expliqué dans le détail hier pourquoi on aurait ces ordres de grandeur. Je n'ai pas lancé ça au hasard, vu que ce genre de choses je passe environ 4 mois par an à le tester, à l'expliquer, à le ré expliquer encore et encore, car ça fait partie de mon métier (depuis maintenant 4 ans). Je ne me considère pas comme un expert, mais on va dire que j'ai suffisamment de math en poche et d'expérience pour comprendre le process dans le détail (avec les étudiants, on fouine même l'assembleur produit par les différentes options de compil de gcc pour comprendre les subtilités, les magic numbers pour transformer des divisions en simples multiplications etc).
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 23:28. Évalué à 1.
        
        Fais les bench toi même
        
        $ time ./bench_dec.py
        real 0m0,049s
        user 0m0,048s
        sys 0m0,004s
        
        time ./bench_float.py
        real 0m0,040s
        user 0m0,036s
        sys 0m0,004s
        
        $cat bench_dec.py
        
        #!/usr/bin/python3 from decimal import Decimal i=Decimal('0.0') a=Decimal('0.000375') m=Decimal('100.0') while ( i < m ): i+=a
        
        $cat bench_float.py
        
        #!/usr/bin/python3 i=0.0 a=0.000375 m=100.0 while ( i < m ): i+=a
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 23:38. Évalué à 2. Dernière modification le 22 décembre 2017 à 23:39.
        
        Tu as une machine étonnante dis donc !!!
        
        Chez moi:
        
        23:31:14 ~/Téléchargements: time python bench_dec.py real 0m3,668s user 0m4,009s sys 0m0,011s 23:31:23 ~/Téléchargements: nano bench.py 23:32:04 ~/Téléchargements: time python bench.py real 0m0,058s user 0m0,067s sys 0m0,000s 23:32:07 ~/Téléchargements: python Python 3.6.3 (default, Oct 24 2017, 14:48:20) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 3.6/0.06 60.00000000000001 >>>
        
        On retrouve donc un facteur 60 sur ce test, ce que j'avais anticipé hier.
        
        Tu n'aurais pas appliqué ton bench deux fois sur le même fichier :) :) Quel coquinou tu fais !!
        
        Ca devient ridicule non ? Si quelqu'un de non étourdi (ou simplement honnête) veut bien faire le test pour confirmer, parce que là, franchement, les mots me manquent…
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 23:57. Évalué à -1.
        
        As-tu essayé mes fichiers, exactement ? J'insiste sur Python3 en en-tête.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 00:32. Évalué à 3.
        
        Tu me prends pour quoi là au juste ?
        Tu es pathétique.
        J'espère juste qu'une bonne dizaine de personnes te mettent ton nez dans ta crotte, mais je ne suis même pas persuadé que ça suffirait à régler ton problème psychologique.
        Fin de partie pour moi.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par kantien le 23 décembre 2017 à 00:24. Évalué à 2. Dernière modification le 23 décembre 2017 à 00:27.
        
        $ time ./bench_dec.py real 0m0,106s user 0m0,100s sys 0m0,004s
        
        $ time ./bench_float.py real 0m0,076s user 0m0,076s sys 0m0,000s
        
        faut lancer le script en direct via le shebang #!/usr/bin/python3, sinon :
        
        $ time python bench_dec.py real 0m5,051s user 0m5,044s sys 0m0,000s
        
        ;-)
        
        Le calcul en décimal est performant (c'est assez normal), mais son usage me semble toujours bien limité pour en faire le comportement par défaut. Il ferait mieux d'ajouter une syntaxe particulière de littéraux pour eux, que d'en faire la solution par défaut et de rajouter des testes dynamiques pour savoir s'il faut changer de représentation (ce qui dégraderait encore plus les performances).
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par Arthur Accroc le 23 décembre 2017 à 13:22. Évalué à 4.
        
        J’obtiens des résultats similaires à ceux de snowball :
        
        $ time /tmp/bench_float.py real 0m0,087s user 0m0,080s sys 0m0,007s $ time /tmp/bench_dec.py real 0m4,767s user 0m4,753s sys 0m0,014s $ /usr/bin/python3 Python 3.6.3 (default, Oct 24 2017, 14:48:20) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 4.742/0.087 54.50574712643679
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 23:45. Évalué à 1.
        
        Ah bah tiens, c'est pas la peine, quelqu'un d'autre a déjà confirmé que tu es un gros coquinou et trouve exactement le même ordre de grandeur que moi :) Etrange non ??
        
        https://i.imgur.com/veuEkqb.png
        
        Fais gaffe, ça devient pathétique ta mauvaise foi.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par jben le 22 décembre 2017 à 23:55. Évalué à 3.
        
        Je l'avais aussi testé de mon coté, avec en plus fractions. Je n'ai pas redonné les codes, c'est les mêmes, exepté pour fractions où l'adaptation est triviale:
        
        i=fractions.Fraction(0) a=fractions.Fraction(375,1000000) m=fractions.Fraction(100)
        
        (oui ma machine est lente, mais le rapport reste cohérent).
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 00:00. Évalué à 1.
        
        Merci beaucoup de ta confirmation.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 23:58. Évalué à 1.
        
        Ah bah tiens, c'est pas la peine, quelqu'un d'autre a déjà confirmé
        
        Il a utilisé Python2. L'implémentation de Decimal est complètement différente.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par jben le 23 décembre 2017 à 00:05. Évalué à 2.
        
        Ah tiens c'est marrant (dans l'ordre float, fractions, decimal:
        
        python3.6: .11, 2.65, 4.96
        
        python3.5: .10, 2.51, .11
        
        python2: .10, 2.81, 5.12
        
        Notons que python3.5 est celui compilé par ma distrib, python3.6 est une version perso. Si ça se trouve, il n'y a pas de tentatives d'escroquerie, juste des comportements étranges.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 23 décembre 2017 à 00:08. Évalué à 3.
        
        Si ça se trouve, il n'y a pas de tentatives d'escroquerie
        
        C'est gentil ça dis-donc. Merci.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 00:12. Évalué à 1.
        
        Tes résultats confirment exactement un ratio de 50 sauf python3.5. Ton Python3.5 n'a visiblement pas utilisé le module decimal ou bien celui-ci a utilisé des floats.
        
        Merci pour les tests en tout cas.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 00:06. Évalué à 0.
        
        00:01:07 ~/Téléchargements: time python2 bench.py real 0m0,071s user 0m0,083s sys 0m0,000s 00:01:11 ~/Téléchargements: time python2 bench_dec.py real 0m3,525s user 0m3,923s sys 0m0,005s 00:01:24 ~/Téléchargements: python Python 3.6.3 (default, Oct 24 2017, 14:48:20) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 3.5/0.07 49.99999999999999
        
        C'est pas assez clair là ?
        Arrête tes conneries, franchement tu deviens ridicule. C'est limite pathologique.
        
        Tu peux tester perl5 vs perl6 tu verras un ratio de même ordre de grandeur.
        Tu peux tester perl6 : num/Rat tu verras un ratio de même ordre de grandeur.
        
        C'est pas un hasard punaise ! C'est juste des maths ! Et c'est normal parce qu'on fait des maths là ! C'est prévisible, calculable, démontrable…c'est juste du raisonnement.
        Je t'ai expliqué dans le détail la prévision hier (tu sais, le truc que tu n'as pas voulu lire….)
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 23 décembre 2017 à 00:09. Évalué à 2.
        
        C'est pas assez clair là ?
        
        Oui, c'est clair : tu utilises Python2.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 00:16. Évalué à 2. Dernière modification le 23 décembre 2017 à 00:21.
        
        J'ai utilisé les deux à ta demande. J'ai copié collé mes benchs. On est trois à l'avoir fait, on a tous les mêmes ratios. Tu te fiches royalement du monde…
        
        00:13:36 ~/Téléchargements: python Python 3.6.3 (default, Oct 24 2017, 14:48:20) [GCC 7.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 00:13:41 ~/Téléchargements: python2 Python 2.7.14 (default, Sep 20 2017, 01:25:59) [GCC 7.2.0] on linux2 Type "help", "copyright", "credits" or "license" for more information.
        
        L'utilisation de l'un ou de l'autre n'a quasiment aucune incidence cf ces tests:
        
        https://i.imgur.com/lbQZo1K.png
        
        un ration de 50 que ce soit pour python3.6 ou python2.7
        Ce ne sont pas mes tests, mais ce sont les prévisions que j'ai données hier. Tu ne peux pas avoir l'honnêteté de reconnaître la réalité ?
        J'ai même pas envie de te dire ce que je pense de ton comportement sur ce forum.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 23 décembre 2017 à 00:25. Évalué à 1.
        
        Je te jure que je me fous pas de ta gueule (je suis con, mais il y a des limites). Je ne te ments pas. Moi aussi j'ai Python 3.5 et moi aussi j'observe un surcoût de Decimal de l'ordre de 10% uniquement.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 00:35. Évalué à 3.
        
        Tu sais quoi ? C'est magique !
        Ton python3.5 il gère un numérateur, un dénominateur, un calcul de pgcd, une division par ce pgcd pour le coût d'une seule multiplication de deux floats parce qu'en fait ta version de python, elle a transformé ta machine en ordinateur quantique… c'est de la maaaagiiiiiiiiie !!!
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 09:26. Évalué à 2.
        
        Voilà le code issu du module decimal servant à additionner deux décimaux.
        J'ai commenté les différentes parties en surbrillance. Je précise que c'est en python3.
        
        def __add__(self, other, context=None): """Returns self + other. -INF + INF (or the reverse) cause InvalidOperation errors. """ other = _convert_other(other) if other is NotImplemented: return other if context is None: context = getcontext() if self._is_special or other._is_special: ans = self._check_nans(other, context) if ans: return ans if self._isinfinity(): # If both INF, same sign => same as both, opposite => error. if self._sign != other._sign and other._isinfinity(): return context._raise_error(InvalidOperation, '-INF + INF') return Decimal(self) if other._isinfinity(): return Decimal(other) # Can't both be infinity here exp = min(self._exp, other._exp) negativezero = 0 if context.rounding == ROUND_FLOOR and self._sign != other._sign: # If the answer is 0, the sign should be negative, in this case. negativezero = 1 def __add__(self, other, context=None): """Returns self + other. -INF + INF (or the reverse) cause InvalidOperation errors. """ other = _convert_other(other) if other is NotImplemented: return other if context is None: context = getcontext() if self._is_special or other._is_special: ans = self._check_nans(other, context) if ans: return ans if self._isinfinity(): # If both INF, same sign => same as both, opposite => error. if self._sign != other._sign and other._isinfinity(): return context._raise_error(InvalidOperation, '-INF + INF') return Decimal(self) if other._isinfinity(): return Decimal(other) # Can't both be infinity here exp = min(self._exp, other._exp) negativezero = 0 if context.rounding == ROUND_FLOOR and self._sign != other._sign: # If the answer is 0, the sign should be negative, in this case. negativezero = 1 if not self and not other: sign = min(self._sign, other._sign) if negativezero: sign = 1 ans = _dec_from_triple(sign, '0', exp) ans = ans._fix(context) return ans if not self: exp = max(exp, other._exp - context.prec-1) ans = other._rescale(exp, context.rounding) ans = ans._fix(context) return ans if not other: exp = max(exp, self._exp - context.prec-1) ans = self._rescale(exp, context.rounding) ans = ans._fix(context) return ans op1 = _WorkRep(self) op2 = _WorkRep(other) op1, op2 = _normalize(op1, op2, context.prec) result = _WorkRep() if op1.sign != op2.sign: # Equal and opposite if op1.int == op2.int: ans = _dec_from_triple(negativezero, '0', exp) ans = ans._fix(context) return ans if op1.int < op2.int: op1, op2 = op2, op1 # OK, now abs(op1) > abs(op2) if op1.sign == 1: result.sign = 1 op1.sign, op2.sign = op2.sign, op1.sign else: result.sign = 0 # So we know the sign, and op1 > 0. elif op1.sign == 1: result.sign = 1 op1.sign, op2.sign = (0, 0) else: result.sign = 0 # Now, op1 > abs(op2) > 0 // 'A ce stade, on n a toujours pas commencé à additionner. Combien ont coûté toutes ces opérations ????' if op2.sign == 0: #' Ca y est, ils se mettent à additionner les numérateurs !!' result.int = op1.int + op2.int else: result.int = op1.int - op2.int // ou les soustraire suivant les signes // 'Et c est reparti pour renormaliser le tout !!!' result.exp = op1.exp ans = Decimal(result) ans = ans._fix(context) return ans if not self and not other: sign = min(self._sign, other._sign) if negativezero: sign = 1 ans = _dec_from_triple(sign, '0', exp) ans = ans._fix(context) return ans if not self: exp = max(exp, other._exp - context.prec-1) ans = other._rescale(exp, context.rounding) ans = ans._fix(context) return ans if not other: exp = max(exp, self._exp - context.prec-1) ans = self._rescale(exp, context.rounding) ans = ans._fix(context) return ans op1 = _WorkRep(self) op2 = _WorkRep(other) op1, op2 = _normalize(op1, op2, context.prec) result = _WorkRep() if op1.sign != op2.sign: # Equal and opposite if op1.int == op2.int: ans = _dec_from_triple(negativezero, '0', exp) ans = ans._fix(context) return ans if op1.int < op2.int: op1, op2 = op2, op1 # OK, now abs(op1) > abs(op2) if op1.sign == 1: result.sign = 1 op1.sign, op2.sign = op2.sign, op1.sign else: result.sign = 0 # So we know the sign, and op1 > 0. elif op1.sign == 1: result.sign = 1 op1.sign, op2.sign = (0, 0) else: result.sign = 0 # Now, op1 > abs(op2) > 0 if op2.sign == 0: result.int = op1.int + op2.int else: result.int = op1.int - op2.int result.exp = op1.exp ans = Decimal(result) ans = ans._fix(context) return ans
        
        En version float: c'est une seule ligne de code directement envoyée à la FPU et qui prend deux cycles d'horloge (impossible de faire moins).
        Rien que les 10 premières lignes de test de ce module prennent 10 fois plus d'opérations élémentaires.
        Donc si ton module decimal prend le même temps qu'avec les floats c'est que ton module est bogué et qu'il est resté en float tout le temps.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par kantien le 23 décembre 2017 à 15:45. Évalué à 3.
        
        Il doit y avoir une erreur dans ton installation de python. Là tu nous sors l'implémentation en pure python, là où normalement tu devrais avoir une implémentation en C du module. Que te réponds cette commande :
        
        >>> decimal.__libmpdec_version__ '2.4.2'
        
        Ça reste moins performant que des float (ce qui était prévisible) mais pas dans de telle proportion. Pour un comparatif avec des benchs plus précis, voir le site de libmpdec (c'est plutôt du simple au double pour les opérations de bases : addition, multiplication, division).
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 23 décembre 2017 à 20:49. Évalué à 0.
        
        J'aime bcp cet extrait :
        
        Pi, 64-bit Python floats cdecimal cdecimal-nt [1] gmpy decimal Java [2] 9 digits 0.12s 0.27s 0.24s 0.52s 17.61s 0.38s 19 digits - 0.58s 0.55s 0.52s 42.75s 0.73s 38 digits - 1.32s 1.21s 1.07s - 1.25s 100 digits - 4.52s 4.08s 3.57s - 5.35s
        
        C'est magnifique, merci.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par Arthur Accroc le 23 décembre 2017 à 23:48. Évalué à 2.
        
        Il doit y avoir une erreur dans ton installation de python. Là tu nous sors l'implémentation en pure python, là où normalement tu devrais avoir une implémentation en C du module. Que te réponds cette commande :
        
        >>> decimal.__libmpdec_version__ '2.4.2'
        
        Bien vu, j’ai regardé de mon côté : une erreur.
        
        En fouillant plus, le paquet mpdecimal n’était pas installé.
        Si je l’installe, j’obtiens cette fois des résultats proches de ceux de gUI :
        
        $ time /tmp/bench_float.py real 0m0,083s user 0m0,080s sys 0m0,004s $ time /tmp/bench_dec.py real 0m0,091s user 0m0,087s sys 0m0,004s
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 09:07. Évalué à -3. Dernière modification le 23 décembre 2017 à 09:11.
        
        Le plus rigolo dans tout ça c'est qu'ils ont pas percuté que tu écris i<m au lieu de i<m+epsilon, ce qui peut aboutir à un résultat faux en fonction des valeurs de i a et m. Tandis que le +epsilon t'amèneras à d'autres résultats tout aussi faux pour d'autres valeurs en entrée. De plus si a est trop petit et le nombre d'itérations très grand on retombe sur un cas typique où le float va se vautrer péniblement (1.+1.+… 1000 milliards de fois et ton double n'aura plus que la précision d'un float…)
        
        Une lacune qui aurait été pardonnable s'ils n'avaient pas fait preuve d'autant d'arrogance mal placée…
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 10:05. Évalué à -5.
        
        Moi aussi je veux jouer !
        
        def x(a,b): n = 0 r = 0 while r < b: r += a n += 1 print(n) i = 1 while i < 1000000000: x(i/6,i) i *= 10
        
        Et voilà j'ai enfin compris pourquoi on parle d'ordinateur quantique depuis le début !
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 12:42. Évalué à 2.
        
        from decimal import * i = Decimal('3')*(Decimal('1')/Decimal('3')) - Decimal('1') # Donc i=0 pour tout enfant de CM1 for n in range (28): i*=10 print(i) # devrait afficher 0 pour tout enfant de CM1
        
        12:34:43 ~/Téléchargements: python aussi_absurde.py -1
        
        Si tu voulais démontrer que float et decimal ne peuvent pas compter de façon exacte et fournissent rapidement des aberrations quelque soit l'implémentation retenue, bravo, ça fait 300 posts qu'on explique pourquoi. Et en plus tu sais quoi, on le prouve, on l'anticipe, on a largement dépassé ce stade de la compréhension avant même d'avoir construit les premiers processeurs.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 23:06. Évalué à 1.
        
        Preuve en image des benchs que j'ai donnés cet après midi
        
        https://i.imgur.com/wUyMfO7.png
        
        Divise 10.5 par 2.21, tu trouves un facteur de combien ?
        
        Hier tu m'as écrit ça
        
        https://i.imgur.com/wUyMfO7.png (t'es gonflé quand même, vu comment ils ont totalement abandonné l'idée)
        
        Je t'ai répondu ça
        
        https://i.imgur.com/y0JB1wt.png
        
        Puis tu m'as totalement méprisé avec cette réponse (intelligente tu crois ?)
        
        https://i.imgur.com/axZ1kIk.png
        
        Tu n'aurais pas raté des dizaines d'occasion de te taire ?
        
        Sans parler du moment où tu penses que je serai ridiculisé bientôt devant mes étudiants en me disant, qu'heureusement, je suis sous un pseudo alors même que j'ai donné un lien avec mon cours et mon vrai nom….Bref…t'as franchement pas fait fort…
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 23 décembre 2017 à 20:41. Évalué à -4.
        
        Sans parler du moment où tu penses que je serai ridiculisé bientôt devant mes étudiants en me disant, qu'heureusement, je suis sous un pseudo alors même que j'ai donné un lien avec mon cours et mon vrai nom….Bref…t'as franchement pas fait fort…
        
        Je la mets aussi celle-ci dans le poster de tes meilleures répliques que je vais envoyer à ton école ? Je l'adresse à qui d'ailleurs, à l'accueil ou au responsable du service pédagogique ?
        
        Je prépare un beau mix de répliques techniques (il y en a des formidables, mélangé aux citations de Kant ça va être magnifique) mais aussi humiliantes (mon intelligence, mon nez dans le caca, tout ça…).
        
        (non, je rigole, mais j'espère sincèrement que tu comptes pas t'en tirer en faisant le mort. tu pourrais par exemple rédiger une dépêche sur l'implémentation Decimal selon IBM, tu apprendrais énormément de choses sur les façons dont un ordinateur peut compter).
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 27 décembre 2017 à 12:50. Évalué à 0.
        
        Un peu de lecture, https://linuxfr.org/nodes/113338/comments/1725062
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 28 décembre 2017 à 11:23. Évalué à -5.
        
        Oui, j'ai vu que tu as enfin admis qu'en Python (le sujet du journal, tu te souviens ?) ça prend pas nécessairement x50 de faire un calcul exact.
        
        On est donc passé de :
        - c'est pas possible
        à :
        - c'est possible mais ça prend x50
        puis à :
        - c'est possible, et ça prend pas x50 tellement Python il est mauvais niveau perfos
        
        On progresse, mais que c'est dur !
        
        Au passage j'ai pertinenté le post de Nicolas. Je ne l'avais pas fait jusque-là, je ne suis pas fan des messages aussi catégoriques, mais ta démonstration m'a convaincu : les perfos ne sont pas un critère pertinent pour les choix par défaut de Python.
        
        Ensuite il te reste à comprendre la différence fondamentale qui reste entre écrire "float f=0.1" en C et "f=0.1" en Python pour finir de comprendre ce que j'essaie de dire depuis 400 posts déjà…
        
        Courage, j'ai confiance en toi, tu peux y arriver :)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 28 décembre 2017 à 13:24. Évalué à 5.
        
        c'est possible, et ça prend pas x50 tellement Python il est mauvais niveau perfos
        
        Tu verras une différence de perfo de l'ordre de x50 lorsque ta boucle python devra faire, à chaque tour, disons une dizaine d'appels à la lib C decimal, c'est à dire quand le coût de la boucle python sera devenue négligeable. Le bench qui consistait à n'exécuter qu'un appel à une lib C ne permet pas de mesurer ce qu'on souhaite mais plutôt le coût de la boucle python.
        
        Il y a aura eu, de toutes façons, quoique tu fasses, une multiplication par 50 des cycles nécessaires en interne pour finalement calculer les mêmes approximations dans 99.9999999999% des cas (pour 1000 milliards d'opérations sur des mantisses de 13 chiffres, en moyenne environ une seule concerne une opération exacte sur deux décimaux). C'est un gâchis énergétique pour une simple focalisation excessive sur l'une des approximations que fait, de toutes façons, la machine dans 99.9999999999% des cas.
        
        Etant donné que ni decimal, ni float, ne règlent le problème élémentaire 3 * 1/3 = 1, ni 7 * 1/7 = 1 ni etc…, les informaticiens ont fait le choix de la base 2, qui a l'avantage d'être parfaitement adapté aux machines classiques, donc plus efficace et moins énergivore.
        
        Si un jour chez Python, ils se mettaient à faire ça par défaut, il y aurait un impact majeur pour toutes les applications utilisant fortement float (traitement d'image, vidéo etc) pour lesquelles il n'y aurait aucun bénéfice sinon une division de perfs par 50 pour les plus gourmandes en calcul et par 2 ou 3 les autres. Côté client c'est donc presqu'à chaque fois totalement nul: perte de temps, d'énergie, et aucun bénéfice concret sur sa vidéo ou son image.
        
        Le seul cas intéressant serait pour des applications financières qui font de la virgule fixe ou quand on se sert de python comme une calculatrice. Pour cela, le module decimal python a été développé, qui gère de la base 10, c'est coûteux évidemment, mais si on a ce besoin spécifique, ça existe, dans d'autres langages aussi d'ailleurs.
        
        Du coup, y a aucun problème, il est urgent de ne rien toucher !
        
        Ensuite il te reste à comprendre la différence fondamentale qui reste entre écrire "float f=0.1" en C et "f=0.1" en Python pour finir de comprendre ce que j'essaie de dire depuis 400 posts déjà…
        
        Oui, j'ai effectivement besoin de comprendre (enfin de moins en moins je crois).
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par kantien le 28 décembre 2017 à 19:10. Évalué à 4.
        
        c'est possible, et ça prend pas x50 tellement Python il est mauvais niveau perfos
        
        Tu verras une différence de perfo de l'ordre de x50 lorsque ta boucle python devra faire, à chaque tour, disons une dizaine d'appels à la lib C decimal, c'est à dire quand le coût de la boucle python sera devenue négligeable. Le bench qui consistait à n'exécuter qu'un appel à une lib C ne permet pas de mesurer ce qu'on souhaite mais plutôt le coût de la boucle python.
        
        Rien n'est moins sûr. Le modèle d'exécution de python est bien différent de celui du C.
        
        cat << EOF > /tmp/test_dec.py > from decimal import Decimal as D > a, mul = D('1.01'), D('1.000001') > for i in range(0, 100): > EOF cat << EOF > /tmp/test_float.py >a, mul = 1.01, 1.000001 >for i in range(0, 100): >EOF for i in `seq 10000` > do echo " a *= mul" >> /tmp/test_dec.py > echo " a *= mul" >> /tmp/test_float.py > done
        
        Là, je fais 100 boucles avec 10_000 multiplication par boucles.
        
        time python3 -c "for i in range(0, 100): pass"; time python3 /tmp/test_dec.py ; time python3 /tmp/test_float.py real 0m0,026s user 0m0,016s sys 0m0,012s real 0m0,344s user 0m0,268s sys 0m0,032s real 0m0,178s user 0m0,172s sys 0m0,004s
        
        Le temps de la boucle est négligeable et le facteur est toujours de 2.
        
        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. >>> (0.344 - 0.026) / (0.178 - 0.026) 2.0921052631578942
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 29 décembre 2017 à 01:44. Évalué à 1.
        
        Ah donc c'est encore pire, c'est carrément l'affectation entre deux décimaux ou l'appel à la lib C qui bouffe tout ce temps. Ca va être compliqué d'y changer quoi que ce soit. J'imagine en plus l'usine à gaz, s'il fallait contrôler les affectations pour voir si l'opérande peut représenter un décimal ou non, auquel il faudrait basculer dans un autre type, donc convertir (avec le coût de la conversion au passage).
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 23 décembre 2017 à 09:08. Évalué à 2.
        
        Je t'explique sincèrement ma vision de la discussion, parce que je ne voudrais pas que tu partes avec la vision d'un escroc. Borné, je te le concède, mais je ne suis pas un menteur. Je suis peut-être con (j'écoute assez Brassens pour le savoir), mais pas méchant, non.
        
        Dis moi, t'es fâché avec les maths en vrai, c'est ça non ?
        
        Non, je ne suis pas fâché avec les maths. Si je dois être fâché avec qqchose, c'est avec ton utilisation des maths.
        
        Tu as utilisé les maths pour montrer que "ce que je veux" n'est pas possible
        
        Tu n'as pas utilisé les maths quand tu m'as dit que 1/3 n'étant pas représentable par un type nommé Decimal était un argument contre son utilisation face à un float qui ne peut de toutes façons pas non plus représenter 1/3
        
        J'attendais que tu me dises qu'on ne peut pas représenter racine(2) dans un Rationnal (et encore plus évidemment même pb pour le float), mais je ne pense pas que ce soit apparu
        
        Tu n'as pas utilisé les maths pour me démontrer que 2 - 1.8 - 0.2 = 0 et que c'est indiscutable, même à 10^-17 près
        
        Ensuite tu as utilisé à nouveau les maths pour montrer que "ce que je veux" est possible, mais met 50x plus de temps
        
        Constatant cette avancée dans ta vision de "ce que je veux", je me suis dit qu'on pouvait peut-être avancer encore, en disant que c'est peut-être pas le meilleur choix, mais c'est pas déconnant quoi (c'est juste ce que je demande dans cette histoire)
        
        Intuitivement, je ne m'attendais pas du tout à un x50, mais plutôt à x2, x3 grand max, qui déjà serait pas facile à justifier comme choix. Mais 50x c'est clairement injustifiable.
        
        Je n'ai pas lu ta démonstration du 50x, (mais je le ferai à tête reposée). Je me disais simplement que t'as dû encore démontrer autre chose que ce qui m'intéresse ici (le sujet du journal : la soustraction de CE2 avec des valeurs exactes…)
        
        Tu sors les benchs, tu tombes sur… x50. Et merde.
        
        En fait le seul bench qui m'intéresse réellement ici c'est prendre la soustraction du journal, la faire tourner 1 million de fois, et voir le temps perdu à la calculer justement (Decimal) par rapport à l'approximer (float). Ca aussi il faut que je le fasse, et je le ferai à tête reposée (j'ai qques idées de benchs qui donnent la justesse du résultat final, le range autorisé selon le type etc.)
        
        Mais dans tous les cas, x50, ça pique
        
        Je regarde ton bench, pour l'exécuter évidemment. Je prends ta routine Python en exemple, je la code de mon côté, je trouve en Decimal un temps de l'ordre de tes temps de float. Curieux… je teste le même en Python2, je trouve x50.
        
        Je te laisse deviner mon interprétation immédiate de la chose (le mec borné tu te souviens ?), surtout que j'ai vaguement vu passer une nouvelle implémentation de la lib Decimal pour Python3 pour améliorer les performances (à regarder aussi à tête reposée)
        
        Ensuite on retombe sur du x50 en Python3.6 et là évidemment ça change tout.
        
        Le fait que Python3.5 soit un cas à part dans les résultats tend à montrer du doigt un bug énorme sur Python3.5 (ou un miracle de la science - mais moi non plus j'y crois pas trop). Ca aussi je veux le regarder à tête reposée : comment un tel bug a pu passer ? Pourquoi la nouvelle lib Decimal en 3.6 donne les même perfos qu'avec l'ancienne en 2.7 ? Comment Perl a pu accepter de perdre x50 (injustifiable, je le dis moi-même) ? Faire des benchs à la va-vite à minuit, c'est sûrement pas la meilleure façon de comprendre
        
        Tout ce que je dis "à regarder à tête reposée", c'est clairement pour comprendre le sujet qui du coup commence sérieusement à m'intéresser, et pas pour savoir kikagagné : à se taper dessus depuis 4 jours à se rabâcher les mêmes choses, je ne suis pas sûr qu'un grand vainqueur existe
        
        Enfin je voudrais dire que je regrette sincèrement l'attaque perso sur le coup des étudiants. C'était un peu suite à tes remarques que j'ai trouvé pompeuses, le côté "je suis prof" alors que ça faisait un moment que tu me répondais des trucs justes évidemment, mais à côté de la plaque (cf le premier point de cette liste). Pour tenter une excuse, tu peux relire le nb de fois où on a attaqué mon intelligence, je pense que j'ai pris ma dose aussi. Mais bon, c'était pas très malin non, et si j'ai fait montre de peu d'intelligence dans ce thread décidément trop long, c'est bien sur ce coup-là.
        
        Voilà, toi et moi on a des choses plus importantes à faire ces temps-ci, mais personnellement je ne clos pas le sujet parce que il n'est pas fini pour moi, j'ai encore trop de questions en suspens.
        
        Passe de bonnes fêtes, et bisous à tout le monde !
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 09:58. Évalué à 2.
        
        Ce que tu ne comprends pas de ton côté, c'est les maths. Je te promets que c'est vraiment le problème de fond. Tu fais un blocage.
        
        Donc tu ne comprends pas les réponses, tu les crois à côté de la plaque. Par exemple, que racine de 2 ne soit pas représentable en machine je n'ai pas besoin de le dire puisque j'ai énoncé plus fort en rappelant que mêmes les rationnels ne le sont pas à cause de limites de la machine qui viennent beaucoup plus vite que tu ne le croîs).
        
        Dès le début tu crois que c'est le nombre de chiffres après la virgule affiché dans un résultat qui indique la précision des calculs faits. Dès le début je vois que tu n'as pas le niveau suffisant pour aborder le sujet. Au bout de 100 posts tu en étais encore à croire que python se trompait dès la première décimale (je cite !), ce qui montre clairement tes limites. Ou bien tu dis que le dernier chiffre affiché par une machine pour 2/3 ne devrait pas être un 7. Ces petits trucs qui ont l'air secondaire pour toi montrent qu'évidemment tu ne comprends pas bien le sujet dont tu parles dès que tu t'adresses à quelqu'un qui bosse sur ça la moitié de l'année.
        
        Comme tu n'as pas le vocabulaire sur les structures algébriques, tu ne comprends pas les problèmes de stabilité non plus.
        
        Tu ne comprends pas non plus les problèmes de dynamique que résolvent les floats et sur lesquels se vautre ton type Decimal en écrivant 10 fois qu'ils ne servent qu'aux perfs. Tu n'as pas non plus imprimé sur le gouffre en terme de mémoire qu'impliquerait ce genre de représentation alors que je t'ai expliqué par un calcul simple les 37,5% de perte.
        
        Tu racontes d'énormes salades en disant que chez Python ça réfléchit à passer à du decimal par défaut alors qu'en fait dans ton lien, Guido explique pourquoi il ne faut surtout pas faire ça (la question n'a duré que deux jours). Il dit la même chose que tous les intervenants ici: il dit des évidences en fait.
        
        Tu ne réfléchis pas techniquement au coût des opérations parce qu'il te manque les maths derrière donc tu crois même qu'additionner des decimaux peut prendre le même temps à 10% près qu'additionner des floats (tiens multiplie les pour voir).
        
        Désolé si c'est dur à entendre pour toi, mais c'est comme ça: si tu n'as pas un niveau suffisant en math pour argumenter sur ce sujet qui t'intéresse, je n'y suis pour rien.
        Par contre, ce sujet est intéressant, et nécessite pas mal de concepts de maths dont j'ai déjà fait la liste. Les apprendre c'est très satisfaisant pour l'esprit. Il n'y a pas d'âge pour se réconcilier avec les mathématiques.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 12:10. Évalué à -2.
        
        Tu crois même qu'additionner des decimaux peut prendre le même temps à 10% près qu'additionner des floats (tiens multiplie les pour voir).
        
        Tu iras expliquer ça aux ingés d'IBM tiens !
        
        Mais mon bon guignol je crois que c'est toi qui va me montrer l'addition ou la multiplication de deux float, avec la normalisation qui va bien derrière, parce que moi je sais pas faire… Moi je me contenterais de faire ça en décimal ce qui me laissera largement le temps d'aller chercher les pop-corn. Et attendre le moment ou tu te rendras compte que tu as dis de la merde.
        
        Ce que tu ne comprends pas de ton côté, c'est les maths
        
        J'ai rien dit jusque là, préférant largement gentiment me foutre de ta gueule. Mais vu le ton insultant que tu prends avec tes interlocuteurs je vais te dire les choses clairement.
        
        C'est toi qui comprend rien aux maths pauvre bouffon ! Tu te rends même pas compte au point où tu en es, que de mauvaise foi en mauvaise foi tu en es venu à raconter n'importe quoi !
        
        Par exemple : les opérations sur flottants impliquent toutes à minima deux opérations (mantisse et exposant) à cela s'ajoute nécessairement une (plusieurs?) normalisations. Et derrière tu te ramasses des erreurs de calculs connues et archi connues dans la discipline (sauf par toi…). N'importe quel analyste aurait crié à l'infamie, aurait eu direct une attaque, face au benchark présenté par gUI parce que c'est typiquement le truc qu'on ne fait jamais CAR LES FLOTTANTS SONT INCAPABLES DE GARANTIR LA FIABILITÉ D'UNE TELLE ITÉRATION. Et toi tranquillement comme si de rien était tu t'amuses à benchmarker… sans te préoccuper si au moins ça renvoi le bon résultat. À l'aise !
        
        Au passage, ce qui te sauve en performance c'est le FPU : des gens ont conçu un matériel spécifiquement optimisé pour traiter les float. Ça n'a rien à voir avec les maths, qui sont contre toi sur ce coup là.
        
        Et dans un autre genre c'est bien la première fois que j'entends parler de dynamique dans les float : à fortiori parce que la première chose qu'on apprend à faire en analyse numérique c'est à normaliser les unités… Typiquement quand je faisais du calcul scientifique je dépassais pas le 10**10 à la louche (ce qui est déjà suspect) : j'aurai préféré une mantisse plus grande sans hésitation aucune, tout ça pour dire que le float tel qu'il est conçu est loin d'être idéal…
        
        Et tout est à l'avenant… Je ne reviendrais pas sur l'histoire des anneaux et des corps gUI vous a déjà foutu le nez dans votre merde et bien comme il faut : il a prouvé qu'il maîtrisait mieux que vous à tel point que j'ai cru qu'il faisait semblant d'être un béotien pour se foutre de votre gueule…
        
        De même pour le benchmarks présenté : vous pousser a tester la performance d'un algorithme qu'on ne code jamais PARCE QUE LA VÉRACITÉ DU RÉSULTAT N'EST PAS GARANTI… Soit gUI sait très bien de quoi il parle et il se fout de votre gueule, soit c'est un pur génie 😂
        
        Alors si c'est pour sortir du quantique, du corps, de l'anneau, et tout le blabla… alors que la base n'est pas maîtrisée. Ça fait de gens tels que toi des incompétents notoires qui cachent leur faiblesse sous un tas de discours grandiloquent pour en imposer face aux autres… un cuistre.
        
        Sur ce, je m'étais promis de ne plus particier à linuxfr à cause de ça. Donc bye bye, sans rancune. J'étais venu juste pour dire à gUI ou d'autres de pas trop se laisser influencer par ce qui se dit ici. Surtout quand on est face à des gens qui cherchent à cacher la misère sous une avalanche de termes et de concepts qu'ils ne maîtrisent pas forcément.
        
        Oh et sur la précision des double et la propagation de l'erreur numérique, tu sais quoi ? Les codes scientifiques modernes se mettent quasi-systématiquement en double… pour comparer à des mesures dont une précision de 20% relèverait du miracle dans certaines disciplines ! Je te laisse deviner pourquoi…
        
        Et puis me fait pas le coup du génie incompris hein ¿ parce que irl c'est connu archi connu et ça ne fait pas débat.
        
        Là question n'est pas de savoir si oui ou non les float/double &co sont merdiques : il est acquis qu'ils le sont. Y compris sur des opérations simples et courantes. Y'a que sur linuxfr qu'on peut prétendre le contraire hein… La question est plutôt de savoir combien de temps on va encore se farcir un historique qui n'a plus lieu d'être… (historique pas si historique que ça puisque comme je l'ai dit le calcul décimal en informatique ça existe, avec des contraintes de performances bien dodues).
        
        Les flottants rendent des services énormes dans certains domaines. Alors oui si jamais Numpy passe en decimal par défaut ce serait une aberration complète. Si c'est ça qui vous inquiète…
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 12:29. Évalué à -6.
        
        PS : ah nan nan c'est pas gUI qui a pondu cette horreur de benchmark. C'est toi. J'te jure des fois y'a des claques qui se perdent…
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 13:07. Évalué à 3.
        
        N'importe quel analyste aurait crié à l'infamie, aurait eu direct une attaque, face au benchark présenté par gUI parce que c'est typiquement le truc qu'on ne fait jamais CAR LES FLOTTANTS SONT INCAPABLES DE GARANTIR LA FIABILITÉ D'UNE TELLE ITÉRATION.
        
        Sans blague ! Ca fait 300 posts qu'on explique que ni float ni decimal ne le permettent.
        La preuve avec decimal (pas la peine de faire beaucoup d'itérations hein)
        
        from decimal import * i = Decimal('3')*(Decimal('1')/Decimal('3')) - Decimal('1') # Donc i=0 for n in range (28): i*=10 print(i) # devrait afficher 0
        
        Les ingénieurs de chez IBM, qui sont autant des singes savants que moi, ne prétendent ni mieux, ni le contraire. D'ailleurs à l'école ils ont appris, à cause de prof débiles comme moi, des maths, les corps, les anneaux, précision relative/absolue, dynamique, virgule fixe, algos d'approximations des fonctions usuelles etc. Les pauvres, toutes ces connaissances, pour apprendre à réfléchir, ça pas dû être facile tous les jours pour eux.
        
        Quant au ton que tu emploies, il est à la hauteur du "contenu".
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 13:38. Évalué à -8.
        
        Sans blague ! Ca fait 300 posts
        
        Et 1 SEUL commentaire de code pour te ridiculiser.
        
        Alors là question mauvaise foi tu bats tous les records. C'est pas moi qui a écrit le code. C'est TOI. Tu peux prétendre m'expliquer les maths. Moi je vais t'apprendre la vie : lorsqu'un mec (parce que t'en es un y'a pas de doute) prétend expliquer la représentation des nombres en informatique et se viande lamentablement sur le premier code qu'il écrit il passe juste pour un bouffon, un débile, un crétin. Il mérite les quolibets les plus acerbes. C'tout.
        
        Quand à ton argument d'autorité, moa-je-suis-prof-de-math, toi-ty-connais-rien (on a élevé les cochons ensemble?), derrière lequel tu t'enfermes dès que tu es en difficulté, tu peux te le mettre là où je pense.
        
        Avec les sincères salutations à tes étudiants.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 13:40. Évalué à 2. Dernière modification le 23 décembre 2017 à 13:42.
        
        As tu compris à quoi servait ce bout de code au moins ? As tu donc compris qu'il n'y a aucune erreur ?
        Indication: pour répondre à la deuxième question, il faut avoir répondu à la première correctement :)
        
        Quant à mes étudiants, j'ai beaucoup de chance, ce sont des singes savants mais, contrairement à d'autres, ils ont un niveau suffisant pour comprendre ces sujets.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 14:06. Évalué à -6.
        
        En attendant que le prof m'explique comment il fait un addition ou une multiplication sur un float… Et en une seule opération. Parce que je sais faire en deux mini, sans compter la renormalisation, mais comme t'es tellement plus intelligent que moi…
        
        De belles paroles, mais des qu'il faut poser ses couilles y'a plus personne…
        
        (Au passage je vais me répéter: un calcul sur décimal est équivalent à un calcul d'entier avec un poil de glue. Donc si les perf. sont à la ramasse c'est un pb d'implémentation, pour les fractions c'est pas violent non plus dans les cas de la vie courante.)
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 14:31. Évalué à 1.
        
        En attendant que le prof m'explique comment il fait un addition ou une multiplication sur un float… Et en une seule opération
        
        Tu sais ce que c'est un pipeline ?
        C'est ça https://fr.wikipedia.org/wiki/Pipeline_(architecture_des_processeurs)
        Il y a plusieurs instructions traitées séparément dans le même cycle d'horloge. C'est comme ça que la FPU arrive à traiter sa mantisse, son exposant, son bit de signe, et les éventuelles exceptions levées par NaN en seulement deux cycles de la FPU.
        
        (Au passage je vais me répéter: un calcul sur décimal est équivalent à un calcul d'entier avec un poil de glue.
        
        C'est là qu'il te manque des maths !
        
        Car si tu dois additionner, tu vas devoir réimplémenter ce que fait IEEE754, mais, là, tu n'as pas de pipeline et en plus tu fais tout en base 10 (donc les multiplications ne sont pas juste des shifts right ou left mais coûtent très cher (6 cycles minimum donc 6 fois plus qu'un décalage) et tu dois vérifier que ça déborde pas, donc faire des soustractions et regarder le bit de signe du résultat etc.
        
        Du coup ça donne le code du module decimal que j'ai collé concernant l'addition. On comprend alors que ta glue, elle coûte au moins largement 100 cycles (et encore ça c'est si fait de façon optimale). Ce n'est pas un problème d'implémentation car il y a des coûts incompressibles.
        
        Et de toute façon, au final, tu auras le même problème qu'avec les binaires mais en base 10 comme je l'ai montré avec le code utilisant decimal concernant la division par 3. Il se plante tout autant que les floats. Tu peux le tester toi même.
        
        Tu peux aussi tester ça
        
        from decimal import Decimal a=decimal('0.000375') s=decimal('0') for i in range (1000000): s += a
        
        et comparer avec
        
        from decimal import Decimal a=0.000375 s=0 for i in range (1000000): s += a
        
        Tu obtiendras
        
        14:05:05 ~/Téléchargements: time python bench_dec.py real 0m10,239s user 0m11,388s sys 0m0,006s 14:05:45 ~/Téléchargements: time python bench_float.py real 0m0,142s user 0m0,161s sys 0m0,007s
        
        Soit une division des perfs par plus de 70. Mais bon, encore une fois, c'était totalement prévisible par …. les maths :)
        
        Voilà monsieur. Avec tout mon respect.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 18:07. Évalué à -9.
        
        Tu sais ce que c'est un pipeline ?
        
        Là tu m'as tuer.
        
        Mais qu'il est con, mais con. Tu fais quoi mercredi soir ? Classe mondiale. Là tu as battu Zenitroll à plate couture. Je te mets sur ma liste.
        
        Tu te rends compte que je balaie la question des performances brutes dès mes 2 3 premiers commentaires précisément à cause de ça ? Tu te rends compte que trop imbu de ta personne tu ne t'ais pas rendu compte que je mentionne des machines qui font du décimal en natif ?
        
        Tu prétends m'apprendre ce que j'ai écrit dans mon tout premier (ou deuxième) commentaire ? T'es grotesque. Ça fait juste deux jours que je me fous de ta gueule pour voir quand tu vas percuter que comparer les perf d'un calcul float à un decimal est totalement débile ! Et toi de débarquer (enfin!) et plutôt que de reconnaître que t'as merdé, tu fais le cador. T'es juste énorme.
        
        J'ai quand même cru que t'allais percuté hier quand tu as écrit "un float sera calculé par le fpu, pas le décimal" : bah oui gros balo ! C'est le f du fpu ! Je relève… Je la joue fine et pas méchant pour un sou mais gros malin que tu es t'as rien vu rien compris…
        
        Par contre tu continues à rabaisser tout ceux qui sont pas d'accord avec toi. Alors comme j'ai besoin de passer mes nerfs, un con qui passait par là. J'ai pas pu résister. Au passage, cela fait de toi un prof particulièrement incompétent, car rabaisser des étudiants comme ça (puisque tu nous prends pour tes étudiants… kofkof) c'est la pire chose à faire point de vue pédagogie.
        
        [^] # Pas la musique…
        
        Posté par Arthur Accroc le 23 décembre 2017 à 14:31. Évalué à 4.
        
        Il y a quand même une conclusion incontestable qui se dégage de cette discussion : les maths, ça n’adoucit pas les mœurs (ou alors peut-être de ceux qui les maîtrisent, mais si c’est pour se faire lyncher par les autres…) ! ;-)
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: Pas la musique…
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 14:35. Évalué à 3.
        
        Bah il s'énerve et il insulte parce qu'il se rend compte, à ses dépends, qu'en math, on peut pas tricher pour masquer son ignorance :)
        Il a l'air aussi un peu aigri et mal dans sa peau (comme en témoignent ses préjugés sur les profs et les étudiants qui sortent d'école d'ingénieur).
        
        [^] # Re: Pas la musique…
        
        Posté par kantien le 23 décembre 2017 à 16:06. Évalué à 2.
        
        Arthur n'a pas tort, le ton est monté inutilement et je te trouve bien agressif également dans ta manière d'intervenir (depuis un moment déjà dans ce journal).
        
        Je pense n'avoir rien à apprendre en mathématique de ta part (peut être en analyse numérique, mais c'est vraiment un domaine qui ne m'a jamais passionné, je trouve cela ennuyeux à mourir), et déjà sur le journal de Blackknight sur le décalage de 64 bits, tu avais tendance à monter sur tes grands chevaux. J'avais tenter, sans succès, de désamorcer la chose par l'humour avec Homer et sa théorie de l'univers en forme de beignet, pour la simple raison que quand je multiplie deux cercles j'obtiens un beignet (la géométrie algébrique, c'est bon mangez-en :-). Et c'est cette structure géométrique (le beignet) qui m'avais permis d'identifier les points pathologiques dans la plupart des langages qui ont fait ce choix (plutôt que le cylindre, produit d'un cercle par un segment, comme Ada) pour des raison de performances sur les X86 (ça évite des tests dynamiques à l'exécution). ;-)
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Le xkcd de circonstance
        
        Posté par Arthur Accroc le 24 décembre 2017 à 00:44. Évalué à 5.
        
        N’oublions pas non plus qu’il faut savoir s’arrêter, pour son propre bien :
        
        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 13:58. Évalué à 2. Dernière modification le 23 décembre 2017 à 13:59.
        
        [le bouffon blabla…] qui se viande lamentablement sur le premier code qu'il écrit
        
        Tu peux expliquer ce que montre mon bout de code juste pour voir ?
        
        Si c'est le test avec m, (d'après ce que j'ai compris ça serait une erreur selon toi :) ;) ;) ), as tu compris que dans ce code on se fiche totalement de passer par m, d'avoir égalité, c'est juste un temps d'arrêt, c'est tout ! Personne n'a demandé à ce que cette valeur soit atteinte par le compteur ou quoi que ce soit du genre.
        
        Si ce test t'embête, tu peux remplacer ça par une boucle déterministe du genre
        
        for n in range (27000): a+=0.000375
        
        Ca ne changera rien et ça montrera de la même manière une division des perfs par 50 (car oui, c'est ce que montre ce bout de code). On n'avait d'ailleurs pas besoin de ce bench puisque j'avais, sans bench, expliqué ce ration d'environ 50, ici même, il y a deux jours, avec des maths de singe savant :) Incroyable non ?
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 14:17. Évalué à -6. Dernière modification le 23 décembre 2017 à 14:18.
        
        Non mais y'a un truc que t'as pas pigé à la base. C'est que j'en avais rien à branler de ton code à la base. Il ne fait que tester deux implémentations.
        
        Et c'est tous le pb de ton argument : tu dis une grosse connerie mathématiquement parlant et tu te sers de l'implémentation informatisé actuelle pour valider tes maths.
        
        C'est débile.
        
        Reste que ça pique les yeux et que ça fait tâche pour quelqu'un qui prétend faire la leçon !
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 14:32. Évalué à 2.
        
        Quelle grosse connerie ? Tu peux expliquer un peu ?
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 14:49. Évalué à 1.
        
        tu te sers de l'implémentation informatisé actuelle pour valider tes maths.
        
        Non car ce ne sont pas mes maths mais les maths. Elles n'ont pas à être validées car on sait prouver qu'elles sont vraies (c'est dingue ça hein ?). Les implémentations qu'on fait de tout ça en info, même si elles sont optimales ces implémentations, auront des coûts incompressibles (ça se démontre aussi. Incroyable les maths en fait !). Et au minimum du minimum tu pourras pas descendra en dessous d'un ratio d'environ 50 (sauf à changer de paradigme en changeant totalement de type de machine -genre quantique puisque tu aimes-).
        
        Ces certitudes sont l'apport des mathématiques que connaissent très bien les ingés d'IBM et tous ces singes savants qui ont compris les concepts dont on parle :) Ton problème c'est que tu les ignores, que visiblement ça te frustre au point d'insulter, d'agresser les autres, et visiblement, ça augmente une aigreur que je sens habituelle chez toi. Je me trompe ?
        
        Bonne journée à toi,
        je te la souhaite la plus agréable qui soit.
        Peace.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par .Nicolas. le 23 décembre 2017 à 18:09. Évalué à -7.
        
        ces certitudes
        
        Ça tu l'es bouffi de certitudes. Y'a aucun doute là-dessus !
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 23 décembre 2017 à 10:12. Évalué à 2.
        
        Cela dit, j'accepte sans problème ton mea culpa et je ne t'en tiens pas du tout rigueur. Au plaisir de te lire et encore une fois, peace !!!!
- [^] # Re: Petit résumé et tests dans la réalité
  
  Posté par Dr BG le 22 décembre 2017 à 16:07. Évalué à 3.
  
  objectivement donné une exécution 48 fois plus lente
  
  Pour être tout à fait juste, Perl6 n'a pas grand chose à voir avec Perl5, c'est une implémentation totalement différente, donc la différence de perf peut tout à fait venir d'autre chose.
  - [^] # Re: Petit résumé et tests dans la réalité
    
    Posté par snowball (site web personnel) le 22 décembre 2017 à 16:12. Évalué à 2.
    
    Bien vu !
    Du coup je viens de faire le test en forçant l'utilisation du float à la place du Rat par défaut et paf ! on revient aux perfs de perl5. Donc c'est bien le Rat qui est en cause. CQFD.
- [^] # Re: Petit résumé et tests dans la réalité
  
  Posté par fearan le 22 décembre 2017 à 16:29. Évalué à 5.
  de mon coté j'ai fait des test avec la même version de python.
```
#!/usr/bin/python
from decimal import Decimal

i=Decimal('0.0')
a=Decimal('0.000375')
m=Decimal('100.0')
while ( i < m ):
        i+=a
```
  real 0m3.492s
  user 0m3.490s
  sys 0m0.003s
  
  et
```
#!/usr/bin/python
from decimal import Decimal

i=0.0
a=0.000375
m=100.0
while ( i < m ):
        i+=a
```
  real 0m0.044s
  user 0m0.036s
  sys 0m0.008s
  
  et encore dans ce cas on s'affranchit du module évaluant si on doit rester en calcul exacte ou pas.
  
  Il ne faut pas décorner les boeufs avant d'avoir semé le vent
  - [^] # Re: Petit résumé et tests dans la réalité
    
    Posté par snowball (site web personnel) le 22 décembre 2017 à 18:06. Évalué à 1.
    Les joyeusetés de perl6 et la quête (absurde) de l'exactitude
    
    On veut calculer la somme des inverses des 1/i pour i de 1 à 47… Ce qui nécessite un minimum de dynamique…
```
my Rat $S = 0.Rat
loop (my $i = 1; $i<= 47; $i = $i +1) {$S = $S + 1 / $i;}
say($S)
```
    bin, ça se vautre… prévisible….
    
    La même avec des floats
```
S=0
for i in range (2,48):
  S += S + 1/i
print (S)
```
    Ca fait exactement ce qu'on attend avec une précision à $10^{-16}$ près… Comme quoi, y a pas qu'une question de perfs qui justifie l'utilisation des floats…
  - [^] # Re: Petit résumé et tests dans la réalité
    
    Posté par gUI (Mastodon) le 22 décembre 2017 à 19:26. Évalué à 0.
    
    Il est amusant ton bench.
    
    Et essaie de l'exécuter avec /usr/bin/python3 , c'est encore plus amusant tu verras :)
    
    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
    - [^] # Re: Petit résumé et tests dans la réalité
      
      Posté par snowball (site web personnel) le 22 décembre 2017 à 19:37. Évalué à 1.
      
      Oui il y a une typo ! C'est S+=1/i (et non S+=S+1/i )
      - [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 19:59. Évalué à 0.
        
        Je parlais du bench Python moi. J'ai comme lui sous Python2, mais plus du tout sous Python3.
        
        Et si tu lis cette conversation, tu verras que l'implementation Decimal (cdecimal) devient plus raisonnable pour un passage à default.
        https://mail.python.org/pipermail/python-ideas/2012-September/016250.html
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 20:27. Évalué à 1.
        
        Et si tu lis cette conversation, tu verras que l'implementation Decimal (cdecimal) devient plus raisonnable pour un passage à default.
        
        Tu peux résumer ce que tu en as compris ? Parce qu'il est intéressant ton lien… Guido n'est pas tendre du tout avec l'idée de passer au Decimal par défaut. C'est limpide, clair: l'absurdité a été rejetée par l'équipe en moins de deux jours !
        
        https://mail.python.org/pipermail/python-ideas/2012-September/016252.html
        
        C'est marrant on dirait mot pour mot ce qu'on t'a répété pendant plus de 100 posts :)
        
        Et la conclusion du thread, ….
        
        https://mail.python.org/pipermail/python-ideas/2012-September/016256.html
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 22:23. Évalué à -1.
        
        Et la conclusion du thread, ….
        
        Pas facile d'interpréter cette conclusion. Tu as lu l'article ?
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 22:24. Évalué à 0.
        
        C'est marrant on dirait mot pour mot ce qu'on t'a répété pendant plus de 100 posts :)
        
        Et j'ai découvert cees conversations après le début des discussions. Je te dis pas le bonheur de voir ces conversations.
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 27 décembre 2017 à 14:14. Évalué à 1.
        
        Et si tu lis cette conversation, tu verras que l'implementation Decimal (cdecimal) devient plus raisonnable pour un passage à default.
        
        Bof, on perd des dizaines de facteurs de performance (cf https://linuxfr.org/nodes/113338/comments/1725062 pour comparer un float*float et un decimal*decimal )
        Quand on noie le tout dans du python ça se voit un peu moins, mais c'est inutilement énergivore (souvent aux alentours de 50 fois plus de cycles) et ça n'a qu'un intérêt ultra limité vu que l'exactitude n'est effective que dans la proportion d'une opération sur 1000 milliards (pour une mantisse sur 13 chiffres).
        
        Les manipulations arithmétiques nécessaires pour traiter les décimaux sont beaucoup plus coûteuses en décimal qu'en binaire.
        Par exemple, les calculs nécessitent en permanence des multiplications et divisions par 10. En base 2, multiplier/diviser par 2 correspond à un seul shift (1 cycle d'horloge). Par contre, multiplier par 10 c'est le coût d'une vraie multiplication (6 cycles) et diviser par 10 coûte environ 12 cycles (grâce à la division magique par une constante connue du compilateur https://stackoverflow.com/questions/30790184/perform-integer-division-using-multiplication )
    - [^] # Re: Petit résumé et tests dans la réalité
      
      Posté par snowball (site web personnel) le 22 décembre 2017 à 20:15. Évalué à 1.
      time python bench.py % bench avec le module decimal sur python3 real 0m3,499s user 0m4,000s sys 0m0,006s
      
      time python bench.py % bench avec des floats sur python3 real 0m0,069s user 0m0,075s sys 0m0,000s
      
      J'obtiens quasiment exactement la même chose avec python2
      
      C'est à dire que le module decimal divise les perfs par 50. C'était totalement prévisible cette baisse énorme de perf non ? Qu'est-ce que tu as trouvé amusant ?
  - [^] # Re: Petit résumé et tests dans la réalité
    
    Posté par jben le 22 décembre 2017 à 19:29. Évalué à 3.
    Ce que je ne comprends pas c'est (en python3)
    - avec les floats (chez moi) : .11s
    - avec des fractions.Fraction (idem) : 2.65s
    - avec des decimal.Decimal (idem) : 4.96s
    Sachant que les rationnels ont plein de propriété sympa, quitte à prendre du temps (et donc pas le comportement par défaut, c'est logique), pourquoi utiliser les decimaux qui ont plein de problèmes en lieu et place des rationnels pour en plus prendre plus de temps ?
    - [^] # Re: Petit résumé et tests dans la réalité
      
      Posté par snowball (site web personnel) le 22 décembre 2017 à 19:51. Évalué à 2.
      
      Je pense qu'en fait ça vient du fait que pour additionner deux fractions a/b+c/d il fait Num=ad+bc et Den=cd. Ensuite il fait un calcul de PGCD pour diviser Num et Den par ce pgcd.
      Mais pour les décimaux il faut rajouter une étape qui consiste à chercher un multiple de Den qui est une puissance de 10. Et ça, ça coûte cher, très cher. Visiblement ça coûte autant que l'étape précédente.
      Mais bon de toute façon ça n'a aucun intérêt (sauf dans la proportion de un cas sur des milliards).
- [^] # Re: Petit résumé et tests dans la réalité
  
  Posté par gUI (Mastodon) le 22 décembre 2017 à 19:18. Évalué à 0.
  
  Ouais, t'as raison, en fait c'était une mauvaise idée.
  
  Merci !
  
  En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
  - [^] # Re: Petit résumé et tests dans la réalité
    
    Posté par snowball (site web personnel) le 22 décembre 2017 à 19:27. Évalué à 1.
    
    De rien :)
  - [^] # Re: Petit résumé et tests dans la réalité
    
    Posté par xcomcmdr le 22 décembre 2017 à 19:47. Évalué à 2.
    
    PUTAIN ENFIN !!1!one
    
    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
    - [^] # Re: Petit résumé et tests dans la réalité
      
      Posté par snowball (site web personnel) le 22 décembre 2017 à 20:35. Évalué à 1.
      
      Ne parle pas trop vite, il y retourne là :)
      - [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par gUI (Mastodon) le 22 décembre 2017 à 21:04. Évalué à 1.
        
        Par contre on peut pas nier que le débat s'est élevé grandement. On a sorti perl et python et on fait des essais.
        
        Promis/juré/craché, c'était mon premier script en Perl ! Merci :)
        
        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par kantien le 22 décembre 2017 à 23:05. Évalué à 3.
        
        Par contre on peut pas nier que le débat s'est élevé grandement. On a sorti perl et python et on fait des essais.
        
        Ça dépend du point de vue, pour moi le débat a régressé. Il n'était nul besoin de sortir perl ou python pour constater les résultats : les tests montrent juste ce que la théorie permettait déjà de savoir, et encore, avec des tests on ne prouve jamais autant de chose qu'avec une théorie bien faite (mais bon, malheureusement, il semblait falloir en passer par là pour te raisonner).
        
        Ça me rappelle un ancien journal de rewind dans laquelle l'approche théorique avait été dénigrée, voire présentée comme inutile, par plus d'un intervenant. Je cite à nouveau le passage d'un ouvrage que j'avais cité à l'époque :
        
        On appelle théorie un ensemble même de règles pratiques, lorsque ces règles sont conçues comme des principes ayant une certaine généralité, et que l'on y fait abstraction d'une foule de conditions qui pourtant exercent nécessairement de l'influence sur leur application. Réciproquement on ne donne pas le nom de pratique à toute espèce d'œuvre, mais seulement à la poursuite d'un but, quand on le considère comme l'observation de certains principes de conduite conçue d'une manière générale.
        
        Il est évident qu'entre la théorie et la pratique il doit y avoir encore un intermédiaire qui forme le lien et le passage de l'une à l'autre, quelque complète d'ailleurs que puisse être la théorie. En effet, au concept de l'entendement, qui contient la règle, doit se joindre un acte du Jugement par lequel le praticien discerne si la règle s'applique ou non au cas présent ; et, comme on ne saurait toujours fournir au jugement des règles qui lui servent à se diriger dans ses subsomptions (puisque cela irait à l'infini), on conçoit qu'il y ait des théoriciens qui ne puissent jamais devenir praticiens de leur vie, parce qu'ils manquent de jugement : par exemple des médecins ou des jurisconsultes, qui ont fait d'excellentes études, mais qui, lorsqu'ils ont à donner un conseil, ne savent comment s'y prendre. En revanche, chez ceux qui possèdent ce don de la nature, il peut y avoir défaut de prémisses, c'est-à-dire que la théorie peut être incomplète, car peut-être a-t-elle besoin, pour être complétée, d'essais et d'expériences qui restent encore à faire; c'est de là que le médecin qui sort de son école, ou l’agriculteur, ou le financier, peut et doit abstraire de nouvelles règles pour compléter sa théorie. Ce n’est pas alors la faute de la théorie, si elle n’a encore que peu de valeur pour la pratique; cela vient de qu’on n’a pas assez de théorie, de celle que l’homme aurait dû apprendre de l’expérience, et qui est la véritable théorie, alors même que l’on n’est pas en état de la tirer de soi-même et de l’exposer systématiquement, comme un professeur, dans des propositions générales, et que par conséquent on ne saurait avoir aucune prétention au titre de médecin, d’agriculteur ou de financier théoricien. Personne ne peut donc se donner pour un praticien exercé dans une science et mépriser la théorie sans faire preuve d’ignorance dans sa partie; car c’est être vraiment ignorant que de croire que l’on peut dépasser la théorie en tâtonnant dans la voie des essais et des expériences, sans recueillir certains principes (qui constituent proprement ce que l’on nomme théorie) et sans faire de tout ce travail un ensemble (qui, méthodiquement traité, prend le nom de système).
        
        Cependant on souffrira plus patiemment encore un ignorant qui, fier de sa prétendue pratique, déclare la théorie inutile et superflue, qu’un présomptueux qui la proclame bonne pour les écoles (comme une manière d’exercer l’esprit), mais qui soutient qu’il en va tout autrement dans la pratique; que, quand on quitte l’école pour le monde, on s’aperçoit qu’on n’a poursuivi jusque-là que des idées vides et des rêves philosophiques; en un mot que ce qui peut être bon dans la théorie n’a aucune valeur dans la pratique. (C’est ce que l’on exprime souvent aussi de cette manière: telle ou telle proposition est bonne in thesi, mais non in hypothesi.) Or on ne ferait que rire d’un mécanicien ou d’un artilleur empirique qui trancherait sur la mécanique générale ou sur la théorie mathématique de la projection des bombes, en disant que cette théorie, si ingénieusement conçue qu’elle soit, ne vaut rien dans la pratique, parce que, dans l’application, l’expérience donne de tout autres résultats que la théorie. (En effet, si à la première on ajoute la théorie du frottement, et à la seconde celle de la résistance de l’air, c’est-à-dire en général plus de théorie encore, elles s’accorderont parfaitement avec l’expérience.) Mais autre chose est une théorie qui concerne des objets d’intuition, autre chose une théorie dont les objets ne sont représentés qu’au moyen de concepts, comme les objets mathématiques et ceux de la philosophie. Peut-être ces derniers sont-ils susceptibles d'être conçus dans toute leur perfection (du côté de la raison), mais ne le sont-ils pas d'être donnés , et n'offrent-ils ainsi que des idées vides dont on ne saurait faire dans la pratique aucun usage ou qu'un usage dangereux. Par conséquent le proverbe en question pourrait bien avoir sa vérité dans les cas de ce genre. Mais dans une théorie qui est fondée sur le concept du devoir il n'y a plus lieu de craindre l'idéalité vide de ce concept; car ce ne serait pas un devoir de se proposer un certain effet de notre volonté, si cet effet n'était pas possible dans l'expérience (quelque parfaite ou quelque rapprochée de la perfection qu'on pût la concevoir). Or il n'est question dans le présent traité que de cette espèce de théorie.Il n'est pas rare d'entendre soutenir, au grand scandale de la philosophie, que ce qu'elle peut avoir d'exact ne vaut rien dans la pratique ; on dit cela sur un ton fort dédaigneux, en affichant la prétention de réformer la raison par l'expérience, même dans ce qui fait son principal titre de gloire, et en se flattant de voir plus loin et plus sûrement avec des yeux de taupe cloués sur la terre qu'avec ceux d'un être fait pour se tenir debout et regarder le ciel.
        
        Kant, « Sur le proverbe : cela peut être bon en théorie, mais ne vaut rien pratique ».
        
        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
        
        [^] # Re: Petit résumé et tests dans la réalité
        
        Posté par snowball (site web personnel) le 22 décembre 2017 à 23:12. Évalué à 1. Dernière modification le 22 décembre 2017 à 23:14.
        
        En fait, la raison est simple (et a été répétée au moins 10 fois): ses concepts en math sont beaucoup trop légers ce qui le handicape énormément pour comprendre ce qui lui a été dit et pour proposer des choses intéressantes sur un sujet qui concerne………des maths ! Bon cela dit, ça a (pardon, il a) progressé, c'est indéniable :)
        
        Sinon, kantien, ton texte, c'est exactement ça. Rien à ajouter.
# Petit tests de la librairie C decimal (libmpdec)

Posté par snowball (site web personnel) le 24 décembre 2017 à 19:24. Évalué à 10.
Bonjour à tous et noyeux joel !

Pour commencer un petit bench de la librairie et le comparatif avec des float (double)

Un petit test que pourront apprécier ceux qui veulent connaître l'impact de l'utilisation des décimaux dans une machine classique.

Il est réalisable par tout un chacun en se rendant sur le site officiel pour obtenir la dernière version à cette adresse http://www.bytereef.org/mpdecimal/quickstart.html
```
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <mpdecimal.h>

int main()
{
    mpd_context_t ctx;
    mpd_t *a, *mul;
    double fa=1.01, fmul=1.000001;
    clock_t start_clock, end_clock;
    unsigned long long turns = 100000000;


    mpd_init(&ctx, 16);
    ctx.traps = 0;
    a = mpd_new(&ctx);
    mul=mpd_new(&ctx);
    mpd_set_string(a, "1.01", &ctx);
    mpd_set_string(mul,"1.000001",&ctx);
    start_clock = clock();
    for (unsigned long long u=0; u < turns; u++)
    {
      mpd_mul (a,a,mul,&ctx);
    }
    end_clock = clock();

    printf("Decimal time: %f\n",
               (double)(end_clock-start_clock)/(double)CLOCKS_PER_SEC);
    mpd_del(a);

    start_clock = clock();
    for (unsigned long long u=0; u < turns; u++)
    {
    fa*=fmul;
  }
    end_clock = clock();
    printf("Float time: %f\n %f\n",
               (double)(end_clock-start_clock)/(double)(CLOCKS_PER_SEC),fa);  
    return 0;
}
```
Le résultat est que la boucle numéro 1, prend en moyenne 43 fois plus de temps que la seconde qui fait la même chose pour les mêmes valeurs d'opérandes.

Vous trouverez sûrement, si vous testez, des ratios parfois inférieurs, parfois très supérieurs aussi (sur une autre machine c'est aux alentours de 70).

Pour comparer ce qui est comparable, j'ai, conformément à la doc de la librairie, initialisé le contexte à MPD_DECIMAL64 qui correspond à une taille des opérandes de 64 bits comme celle des double sur ma machine (64 bits) qui concerne la deuxième boucle. J'ai compilé avec -O2 dans les options de GCC.

Pourquoi utiliser un bench python faisant appel à une librairie C n'a aucun sens

Parce que la boucle python coûte plus cher que ce qu'on souhaite mesurer (environ 30 fois plus)!
Par contre, si on reste cohérent dans le bench, et qu'on fait du "full python" on retrouve le même ratio (obtenu avec la lib libmpdec) comme l'expérience a déjà été faite dans des posts au dessus.

Etait-ce prévisible ?

Bien évidemment, on se doute, que lorsque l'on remplace une seule instruction assembleur d'addition sur des flottants (qui prend maximum 2 cycles d'horloge FPU), par l'arsenal de cette lib, il devient évident, que la librairie décimale ne peut pas ne prendre que 4 cycles (rien que l'appel à mpd_add et les empilements que ça génère, coûte au moins 10 cycles)

Pourquoi on trouve des benchs qui semblent contradictoires sur le site de la lib

D'abord parce que dans les benchs proposés, les calculs sont noyés dans plein d'autres (exemple, le calcul du mandebrot et son algo d'échappement).
Et peut être aussi, parce que sinon c'est moins attractif (pour être taquin).

Conclusion

Je ne cherche à ridiculiser personne ici, je ne suis pas dans la guéguerre, j'interviens sur un sujet que je pense connaître assez, vu que c'est ma formation et accessoirement mon métier. Quand je dis que quelqu'un a des problèmes math, ça peut être tout simplement vrai et çe n'est pas pour autant que je méprise mon interlocuteur. A l'avenir, par contre, ça serait sympa de pas se faire traiter de con ou de guignol ou que sais-je encore, pour des raisons qui tiennent d'avantage de la lutte d'égo que de la recherche de ce qui est vrai ou faux.

Voilà, bonnes fêtes à tous, bons benchs pour les plus malades d'entre vous (!), et mangez pas trop d'huîtres mélangées au foie gras et au chocolat, c'est moyennement digeste :)
# Commentaire de soutien ;-)

Posté par C138 le 09 janvier 2018 à 13:23. Évalué à -2.

Je viens de me créer un compte exprès pour ça.
Donc juste pour ajouter mon soutien (insignifiant, certes) à reynum…
Je suis tombé des mêmes nues en découvrant ce «détail» (et l'étendue des langages concernés).
Je vais pas faire long, mais juste pour dire qu'en diffusant cette info dans un contexte de labo, plutôt scientifique, développement logiciel (fiabilité et cie), j'ai les mêmes réactions.
En gros on nous explique que pour avoir les performances d'un avion de chasse, on ne pourrait plus voler comme un avion de lignes intérieures…

(Contexte perso : j'ai eu la même formation théorique que beaucoup ici visiblement, j'ai développé des outils d'analyse de langage/grammaire/typage plutôt sérieux, je comprends donc bien également les explications techniques mais j'exprime le même ressenti d'insatisfaction vis à vis de la situation)

PS : (cas particulier, certes) Pour ce qui est d'accepter que "a - a == un chouilla exprimé comme on veut", je ne peux m'empêcher de penser qu'un langage moderne est capable de détecter quand deux noms désignent le même objet et qu'il peut donc se dispenser d'appeler l'artillerie lourde soit-elle une norme internationale et retourner systématiquement 0, sans se poser de question.
[corollaire : dans quel contexte mathématique numérique théorique, x - x n'est pas zéro… ?]

Cela étant, ce fil de discussion est vraiment très très instructif mais certainement pas sur les aspects techniques ;-)
Merci à tous.
- [^] # Re: Commentaire de soutien ;-)
  
  Posté par Benoît Sibaud (site web personnel) le 09 janvier 2018 à 15:35. Évalué à 4.
  [corollaire : dans quel contexte mathématique numérique théorique, x - x n'est pas zéro… ?]
  
  En maths, soustraire des infinis fait rarement zéro. En informatique non plus d'ailleurs.
```
#include <iostream>
#include <cmath>
#include <cfloat>

int main() {
  float x;
  x = NAN;
  std::cout << "x: " << x << " x-x: " << (x-x) << std::endl;
  x = INFINITY;
  std::cout << "x: " << x << " x-x: " << (x-x) << std::endl;
}
```
```
x: nan x-x: nan
x: inf x-x: -nan
```
  - [^] # Re: Commentaire de soutien ;-)
    
    Posté par C138 le 09 janvier 2018 à 16:51. Évalué à -1.
    
    Ah oui, c'est vrai.
    Mais ça reste maîtrisable dans une implémentation d'exclure ou plutôt de traiter spécifiquement ces valeurs.
    Le code donné en est la preuve ;-)
- [^] # Re: Commentaire de soutien ;-)
  
  Posté par kantien le 09 janvier 2018 à 17:55. Évalué à 3.
  corollaire : dans quel contexte mathématique numérique théorique, x - x n'est pas zéro… ?
  
  Dans aucun, même dans l'arithmétique flottante en base 2 (en excluant les infinis, bien sûr ;-).
```
>>> 0.2 - 0.2
0.0
```
  Le principe de l'arithmétique flottante est de traiter des nombres de la forme :
  
  Ce qu'il y a c'est que par défaut, python utilise la base 2 pour traiter les nombres à virgules, conformément à la norme IEEE-754, et que certains nombres décimaux ne sont pas représentables de manière finie dans une telle base (comme 0.2). Néanmoins cette norme a été révisée en 2008 pour y inclure également l'arithmétique flottante en base 10 (ce qu'implémente le module decimal de python) mais elle ne bénéficie pas d'accélération matériel (sauf chez des processeurs utilisés en autres dans la finance : SPARC64, POWER PC (Power 6), IBM System Z9).
  
  En gros on nous explique que pour avoir les performances d'un avion de chasse, on ne pourrait plus voler comme un avion de lignes intérieures…
  
  Non, on te dit d'utiliser le module decimal, il est fait pour cela. ;-)
  
  Cela étant, en base 10 tu auras des problèmes similaires de nombres non représentables, et même en base 2 il faut juste savoir écrire ses opérations :
```
>>> 2.0 - (1.8 +0.2)
0.0
```
  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
  - [^] # Re: Commentaire de soutien ;-)
    
    Posté par C138 le 09 janvier 2018 à 20:31. Évalué à -3.
    
    Je comprends que l'ambiance se dégrade très vite ici. Je vais juste l'écrire paisiblement : commentaire inutile.
    
    a) contexte mathématique numérique théorique et donc justement pas en implémentations informatiques "biaisées"
    Donc, dans les bouquins de mathématiques, (une fraction x - une fraction x) = 0 , (un complexe x - un complexe x) = 0, et même (un ensemble x - un ensemble x) c'est l'ensemble vide (i.e. le "0" des ensembles).
    Exception de valeurs particulière, données par B.Sibaud, qui avait bien compris/lu la remarque.
    
    b) oui, et re-re-oui, on a tous compris l'explication mécanique. J'ai bien tout relu avant de commenter.
    
    c) oui également, Decimal est effectivement un moyen de cacher/surcharger/contourner ce qui "tracasse"
    
    d) exemple inutile. Pas d'étape pathologique inside. À comparer avec 0.2+0.4-0.6 et même avec 0.2-0.6-0.4, où l'erreur affichée n'est pas la même, non commutativité des calculs numériques [/ arrondis] bien connue également…
    
    Fin, bref, ça tourne en rond, pour rien.
    
    Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.
    Perso je vois au moins trois implémentations arithmétiques "decimalo-flottantes" satisfaisantes (au sens naturel du terme)
    * une simple calculatrice scientifique qui couvre correctement son domaine de fonctionnement (exact pour les décimaux usuels, notation ingénieur/scientifique ailleurs)
    * bc, (An arbitrary precision calculator language) même caractéristiques
    * le langage de Google, Go qui semble se comporter comme souhaité. (confirmation/infirmation ?)
    
    Cela est donc bien possible. Que cela ne soit pas le choix de Python (et de bien d'autres langages), ben ok. Mais ça interpelle. C'est tout.
    
    PS : Ah oui, en La(TeX) aussi c'est bon à première vue, 0.2+0.4 donne 0.60000 ;-)
    PS2 : 4ème implémentation déjà évoquée, un tableur. Ça se comporte, suffisamment bien, que ce soit pour les décimaux que pour des valeurs grandes.
    - [^] # Re: Commentaire de soutien ;-)
      
      Posté par kantien le 10 janvier 2018 à 00:24. Évalué à 3.
      Je comprends que l'ambiance se dégrade très vite ici.
      
      Il n'y avait aucune agressivité dans mon commentaire, je ne faisais que résumer ce qui a été dit mainte et mainte fois au cours du fil.
      
      contexte mathématique numérique théorique et donc justement pas en implémentations informatiques "biaisées"
      Donc, dans les bouquins de mathématiques, (une fraction x - une fraction x) = 0 , (un complexe x - un complexe x) = 0, et même (un ensemble x - un ensemble x) c'est l'ensemble vide (i.e. le "0" des ensembles).
      
      Oui, et cela est vrai même en arithmétique flottante quelque soit la base x - x vaut toujours 0, même en informatique « biaisée ».
      
      oui également, Decimal est effectivement un moyen de cacher/surcharger/contourner ce qui "tracasse"
      
      Non, c'est juste le moyen d'avoir accès à de l'arithmétique flottante en base 10, qui est celle que l'on a apprise au primaire. Par défaut les littéraux flottants sont calculés en base 2 en Python (comme dans de nombreux langage). Tu peux toujours utiliser Haskell si tu veux du polymorphisme ad-hoc sur les littéraux flottants.
      
      le langage de Google, Go qui semble se comporter comme souhaité. (confirmation/infirmation ?)
      
      Infirmation ;-)
      
      package main import "fmt" func main() { fmt.Println(0.6 - 0.4 - 0.2) fmt.Println(2.0 - 1.8 - 0.2) }
      
      renvoie
      
      1.8645851828000517e-155 5.593755548400155e-155
      
      Voir la référence sur les constantes en Go.
      
      Fin, bref, ça tourne en rond, pour rien.
      
      Je ne te le fais pas dire. ;-)
      
      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
    - [^] # Re: Commentaire de soutien ;-)
      
      Posté par Michaël (site web personnel) le 10 janvier 2018 à 01:28. Évalué à 3. Dernière modification le 10 janvier 2018 à 01:29.
      
      Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.
      
      C'est pas tellement une histoire de conditionnement mais plutôt le fait que le système actuel est facile à comprendre – quand on programme! – parcequ'il est prévisible: on sait facilement quand tel ou tel langage va utiliser des flottants, ou des entiers, et que dès qu'on veut s'éloigner de ces choses, il faut en gros utiliser une fonctionnalité spéciale. Ce n'est pas ce que ce soir forcément particulièrement agréable ou ébouriffant de confort mais ça marche et ça ne prend pas des décisions arbitraires. Voilà pour le status quo. Quant au status pas quo, c'est une chose de dire qu'un calcul de CE2 pourrait être traité exactement par la machine, et c'en est une autre d'essayer de délimiter les contours d'une fonctionnalité de langage généraliste qui traitent bien les problèmes de CE2 sans rien sacrifier à la simplicité, ni pour le programmeur ni pour l'implémenteur.
    - [^] # Re: Commentaire de soutien ;-)
      
      Posté par snowball (site web personnel) le 10 janvier 2018 à 02:39. Évalué à 2.
      Donc, dans les bouquins de mathématiques, (une fraction x - une fraction x) = 0 , (un complexe x - un complexe x) = 0, et même (un ensemble x - un ensemble x) c'est l'ensemble vide (i.e. le "0" des ensembles).
      
      Chez les flottants aussi, x-x=0.
      
      c) oui également, Decimal est effectivement un moyen de cacher/surcharger/contourner ce qui "tracasse"
      
      Pas vraiment. Ça ne règle le problème Decimal (x) * Decimal (1/x) = Decimal (1) que quand x est de la forme 2*n * 5*m, c'est à dire quasiment jamais (même pas pour x=3 !!).
      
      Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.
      
      Les floats que propose Python sont à destination du milieu geek "conditionné" (i.e qui comprend ce qu'est un float). Python n'est pas une calculatrice. Mais de toute façon, toute personne qui a déjà utilisé sa calculatrice est déjà habituée aux résultats approchés même pour des calculs évidents du genre 3 * 1/3 = 1 et ça ne fait pas sourire. Elle se rend juste compte qu'une machine qui ne gère que du fini, ne peut gérer exactement les nombres: elle ne peut faire, quasiment à chaque fois, que des approximations.
      
      une simple calculatrice scientifique qui couvre correctement son domaine de fonctionnement (exact pour les décimaux usuels, notation ingénieur/scientifique ailleurs)
      
      Non. Une calculatrice de base "se trompe" sur 1.000 000 1 * 0.999 999 9 qui sont deux décimaux très "raisonnables". Elle "se trompe" quasiment sur tous les calculs impliquant les décimaux (en fait la probabilité qu'une calculatrice donne un résultat juste dès qu'elle fait des multiplications ou divisions sur des décimaux aléatoires est de moins d'un milliardième (si on considère une machine sachant gérer 13 chiffres de mantisse).
      
      Cela est donc bien possible.
      
      En fait, bc fait
      01:53:35 ~: bc bc 1.07.1 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 1.01*0.99 .99
      
      C'est à dire un résultat faux. Alors oui, tu peux évidemment pousser la mantisse utilisée par bc un peu plus si tu es "conditionné" aux problèmes que pose le calcul numérique sur une machine, mais tu tomberas sur le même problème un tout petit peu plus loin.
      
      On peut, modulo des coûts de calcul très importants, colmater quelques erreurs (une sur un milliard environ) mais on ne peut pas régler le problème tout court. Il y aura toujours des calculs quasi évidents qui ne seront pas correctement effectués par une machine.
      
      Mais ça interpelle. C'est tout.
      
      Tout comme ça m'a interpellé quand j'ai vu que presque tous les calculs faits par une calculatrice sont faux (sauf pour quelques opérations sur certains décimaux qui donnent une illusion d'exactitude au néophyte)
      
      PS : Ah oui, en La(TeX) aussi c'est bon à première vue, 0.2+0.4 donne 0.60000 ;-)
      
      Il a tronqué un résultat faux au moment de l'affichage et qui du coup redonne une impression d'exactitude du calcul (il arrondit un arrondi faux qui redonne un résultat "exact" )
      
      PS2 : 4ème implémentation déjà évoquée, un tableur. Ça se comporte, suffisamment bien, que ce soit pour les décimaux que pour des valeurs grandes.
      
      Non. Ça fait les mêmes bêtises, puis ça les cache avec des algos qui tentent de prédire ce que veut probablement l'utilisateur (en fonction de la configuration de l'arrondi dans le format de cellule). Calc utilise des floats derrière ton dos, fait, comme toute machine, les mêmes approximations, puis formate l'affichage pour qu'avec certains décimaux tu aies l'illusion que son calcul est juste, ce qui, évidemment, n'est pas vrai dans presque tous les cas.
      
      En fait, il n'y a pas vraiment de problème:
      
      Si tu veux une addition / soustraction exacte des "petits" décimaux, tu as des modules pour ça (par contre ils vont se vautrer quasiment sur chaque division, même élémentaire) et ça va coûter cher en perf.
      
      Si tu as compris, que de toute façon, le calcul juste sur une machine n'arrive que dans quelques cas exceptionnels et qu'une précision aux alentours du 17ème chiffre après la virgule te suffit alors tu as les floats (avec beaucoup d'efficacité machine).
      
      Dans 99% des cas d'utilisation, l'exactitude souhaitée sur quelques rares petits décimaux n'ayant aucun intérêt, et coûtant environ 50 fois plus de cycles d'horloge qu'un calcul avec des floats, on n'a que très rarement l'intérêt d'utiliser le module decimal.
      
      Bref, on a une solution informatique convenable à quasiment tous les problèmes numériques usuels en fonction de chaque besoin spécifique.
      
      Les sciences (mathématique/informatique) ont fait depuis longtemps le tour théorique de cette question en délimitant (démonstration à l'appui) précisément ce qu'on peut faire et ce que l'on ne peut pas faire, ce qu'il est intéressant de faire ou ce qu'il faut éviter de faire dans le domaine de la représentation des nombres en machine.
      
      Tout cela a déjà été dit, dans les posts au dessus, mais certaines incompréhensions ayant nécessité beaucoup d'explications ont fini par noyer les messages très clairs donnés par beaucoup d'intervenants.
      
      Les incompréhensions, quand on creuse un peu, viennent de représentations erronées de la nature même des nombres. Ce n'est pas étonnant car ces concepts sont en fait loin d'être évidents à comprendre surtout quand on croit (sincèrement) les maîtriser.
- [^] # Re: Commentaire de soutien ;-)
  
  Posté par snowball (site web personnel) le 10 janvier 2018 à 02:44. Évalué à 2.
  
  Je vais pas faire long, mais juste pour dire qu'en diffusant cette info dans un contexte de labo, plutôt scientifique, développement logiciel (fiabilité et cie), j'ai les mêmes réactions.
  
  Alors ça, c'est franchement pas rassurant. Cela dit, ces problèmes sont assez rarement enseignés (et derrière il faut finalement avoir compris profondément le concept de nombre en math, ce qui est très, très peu fréquent)
  - [^] # Re: Commentaire de soutien ;-)
    
    Posté par C138 le 10 janvier 2018 à 10:40. Évalué à 0.
    
    Quand je parle de même réaction, c'est pas tellement sur la surprise technique (une fois que les gens ont lu la norme bah ok, ça roule)
    
    Ce qui surprend c'est l'aveuglement [ici, linuxfr] à envisager que la situation puisse choquer quand on la compare à l'intuition habituelle du problème. En gros des problèmes pour les très petites et grandes valeurs, ça ok, tout le monde le sait. Mais sur ce genre de calcul, devoir faire appel à une librairie «spécialisée» (!! ;-)
    
    Mais je suis désolé, et ça va certainement choquer, ce que je veux calculer ce n'est pas «la vérité selon la norme machin qui me rappellera sans arrêt que 0.1 pose problème en binaire» (pas mon problème) mais la vérité mathématique du CE2 à la terminale et plus si affinité, quitte à ce que le logiciel me mente sur son «erreur» (je voulais dire comportement interne).
    
    Ce qui m'intéresse c'est la vérité mathématique et pas la vérité IEEE. Du coups, il y a / aura effectivement un dilemme entre affichages et calculs internes.
    
    Pour contextualiser un peu, j'en suis venu récemment à python (puis ce "problème") parce que Python va être enseigné de plus en plus en lycée. Bon, bah c'est simple : "Madame/Monsieur, votre truc marche pas, il ne sait pas calculer (calculs habituels décimaux) aussi bien que ma calculatrice"
    
    Je vous laisse prendre la place des enseignants qui devraient donc sortir l'artillerie IEEE pour expliquer la situation… ;-)
    - [^] # Re: Commentaire de soutien ;-)
      
      Posté par snowball (site web personnel) le 10 janvier 2018 à 12:07. Évalué à 3.
      
      Ce qui m'intéresse c'est la vérité mathématique et pas la vérité IEEE.
      
      Quand ta calculatrice affiche 2/3=0.6666666666667 la blâmes-tu ? Pourtant ce résultat est tout aussi faux (même davantage car plus imprécis) que quand python fait un calcul du genre 0.1+0.2=0.30000000000000004. C'est exactement le même problème. Ce qui se passe c'est que certains ont une tendance étrange à focaliser sur les décimaux et voudraient absolument qu'avec les décimaux une machine calcule exactement alors qu'ils acceptent que pour d'autres nombres ça ne calcule pas juste.
      
      Cette focalisation sur les décimaux est liée à une mauvaise compréhension de ce que sont les nombres et donc de l'impossibilité de les représenter correctement en machine pour l'immense majorité d'entre eux.
      
      J'ajoute que quand on fait un cours sur la représentation des nombres dans une machine, donc sur l'impossibilité de les représenter correctement (sur une machine quelconque, calculatrice ou autre), il n'y a aucune difficulté. Le tout est d'avoir reçu un cours convenable traitant de ce problème qui est, clairement, un problème de conceptualisation des nombres avant d'être un problème informatique.
      
      J'ajoute que dans les programmes du CE2 on ne commence plus par les décimaux mais par les rationnels depuis plus de 10 ans ce qui explique peut être pourquoi les jeunes élèves du secondaire n'ont pas ce problème de focaliser à ce point sur les décimaux.
      
      L'enseignement antérieur était de calculer d'abord avec les décimaux puis les fractions (en plus on utilisait la monnaie pour parler des décimaux et donc beaucoup d'élèves avaient des difficultés dès qu'il y avait plus que deux chiffres après la virgule). C'était une énorme bêtise sur le plan mathématique puisque les décimaux sont, par définition, des rationnels très particuliers et que toutes les règles de calcul permettant de les manipuler proviennent en fait de celles sur les fractions !
      
      Quant à la vérité mathématique (c'est à dire les calculs exacts j'imagine), c'est tout simplement une utopie sur une machine.
    - [^] # Re: Commentaire de soutien ;-)
      
      Posté par Michaël (site web personnel) le 10 janvier 2018 à 16:19. Évalué à 3.
      
      Ce qui surprend c'est l'aveuglement [ici, linuxfr] à envisager que la situation puisse choquer quand on la compare à l'intuition habituelle du problème.
      
      Le calcul est loin d'être quelque chose d'intuitif, mais bon, ce qui me chagrine le plus c'est le soi-disant aveuglement dont tu parles. Je suis loin d'avoir lu tous les commentaires dans cette discussion, mais il me semble que la surprise causée par le résultat affiché est plutôt consensuelle, ce qui coince c'est l'attitude face à cette surprise: ceux qui disent “il faudrait changer ça” n'entrent jamais dans ne serait ce qu'une esquisse de comment améliorer la situation actuelle face à ceux qui disent “la situation actuelle a ses défauts, mais pour l'instant personne ne sait faire quelque chose de vraiment mieux”.
      
      Bon, bah c'est simple : "Madame/Monsieur, votre truc marche pas, il ne sait pas calculer (calculs habituels décimaux) aussi bien que ma calculatrice"
      
      Si tu parles des calculatrices qui font du calcul symbolique, ce serait l'occasion de faire dévier la discussion sur le plan politique: à ma connaissance personne n'utilise ce genre d'outil hors du contexte scolaire, dès lors comment justifier l'investissement financier pour les élèves et l'effort d'apprentissage pour ce qui n'est finalement rien de plus qu'un gadget? Et plus sérieusement, ce serait l'occasion de découvrir la différence entre le calcul symbolique et le calcul approché.
    - [^] # Re: Commentaire de soutien ;-)
      
      Posté par kantien le 10 janvier 2018 à 16:42. Évalué à 3.
      Ce qui m'intéresse c'est la vérité mathématique et pas la vérité IEEE.
      
      La norme IEEE-754 respecte très bien la vérité mathématique, mais j'y reviendrais après.
      
      Pour contextualiser un peu, j'en suis venu récemment à python (puis ce "problème") parce que Python va être enseigné de plus en plus en lycée. Bon, bah c'est simple : "Madame/Monsieur, votre truc marche pas, il ne sait pas calculer (calculs habituels décimaux) aussi bien que ma calculatrice"
      
      Bien au contraire ! C'est un très bon prétexte pour leur faire travailler leurs mathématiques. :-)
      
      Je m'explique en illustrant par une approche possible (je ne suis pas là pour produire du matériel d'enseignement) en partant de ce que les élèves maîtrisent bien : la base 10 (et c'est cela qui choque dans l'exemple du journal).
      
      >>> import decimal >>> D = decimal.Decimal >>> ctx = decimal.getcontext() >>> ctx.prec = 3
      
      Là je ne fais que charger de quoi travailler avec des nombres flottants en base 10 : des décimaux, en somme; et je fixe une précision assez basse pour avoir de petits nombres.
      
      >>> un, deux, trois = D(1), D(2), D(3) >>> un / trois Decimal('0.333') >>> deux * (un / trois) Decimal('0.666') >>> deux / trois Decimal('0.667')
      
      Hop, on définit les nombres 1, 2, 3 et on fait quelques calculs avec. On voit un peu à quoi correspondait le ctx.prec = 3 de tout à l'heure (pour l'instant, c'est le chiffre de nombre après la virgule). Le résultat de la première opération doit être familière à tout lycéen : il sait que si l'on divise 1 par 3, il aura une infinité de 3 après la virgule et là il n'en garde que trois.
      
      Pour la seconde opération, il sait très bien que 2 * 333 = 666 d'où 2 * 0.333 = 0.666. La fraction a était approximée avant la multiplication, mais ensuite le calcul de celle-ci est on ne peut plus conforme à la « vérité mathématique » (qui te tient tant à cœur). En revanche si l'on pratique directement la division de 2 par 3, puis que l'on approxime au plus proche en ne conservant que trois chiffres après la virgule, on obtient un autre résultat, à savoir 0.667.
      
      On peut continuer et montrer quelques « étrangetés » (qui n'en seront sans doute pas pour des lycéens) du calcul selon les règles strictes de l'arithmétique mais avec des arrondis.
      
      >>> un / trois + un / trois + un / trois Decimal('0.999') >>> trois * (un / trois) Decimal('0.999') >>> un /trois + deux / trois Decimal('1.00')
      
      Et là c'est tout à fait compréhensible. Selon les règles strictes de l'arithmétique, on a bien 333 + 333 + 333 = 3 * 333 = 999. Et pour le dernier, on a bien 333 + 667 = 1000 ou dans notre cas 0.333 + 0.667 = 1.000, mais comme la précision est de 3 il n'affiche que 1.00. En fait la précision c'est la taille de la mantisse, c'est à dire que le nombre est vu comme $100 \times 10^{-2}$ , là où un /trois est vu comme $333 \times 10^{-3}$ .
      
      Illustration du changement de précision :
      
      >>> D(2128) / trois Decimal('709') >>> ctx.prec = 5 >>> D(2128) / trois Decimal('709.33')
      
      Il me semble bien que tout ce qui précède est largement accessible à des lycéens. Il suffit ensuite de développer la chose en leur expliquant que le même genre de phénomène se produit si l'on prend une base 2 au lieu d'une base 10, et que c'est dans cette base que travaille python par défaut.
      
      >>> trois * (un / trois) - un / trois - deux / trois Decimal('-0.00001') >>> 2.0 - 1.8 - 0.2 -5.551115123125783e-17
      
      Les deux « erreurs » de calcul relèvent des mêmes principes mathématiques mais dans deux bases distinctes.
      
      Pour revenir, et conclure, sur cette histoire de standard IEEE. Le calcul flottant en base 2 a été normalisé en 1985 sous le nom de standard IEEE-7554. En 2008, y a été ajouté une normalisation de la base 10 (utilisée ici par Python), et j'avais donné plus haut le lien vers la page de l'ingénieur IBM qui s'en est occupé. Python datant de 1990, les matériels ayant implanté le standard de 1985 dans leur FPU, on peut comprendre pourquoi, par défaut, ce langage utilise la base 2 et non la base 10.
      
      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
# À part bc

Posté par C138 le 09 janvier 2018 à 17:06. Évalué à 0.

Me suis pris au jeu… de trouver des propositions simples et «satisfaisantes» (j'ai pas dit correctes ou incorrectes hein)…

Effectivement, pas grand chose en dehors de bc.
Même Perl est une illusion car même si
echo "print(0.2+0.4)" | perl donne bien 0.6
echo "print(0.2+0.4-0.6)" | perl donne 1.11022302462516e-16 et non pas le tant espéré 0…
Bref, je viens de tomber sur un langage que ce petit test (heuristique oui) ne met pas en défaut, ça se passe ici :
https://golang.org/#
avec fmt.Println(0.2+0.4-0.6) ça donne bien 0

C'est peut-être le Println qui cache la forêt… ??
# Que disent les programmes du primaire

Posté par snowball (site web personnel) le 10 janvier 2018 à 13:24. Évalué à 4.
Pour compléter un peu, je suis allé vérifier la progression pédagogique concernant les nombres.

Donc, pas de décimaux ni de fractions avant le CM1.

A partir du CM1, depuis 2008, la progression est la suivante:
- D'abord les fractions
- Ensuite les fractions dites décimales et leur écriture à l'aide de la notation décimale (virgule). Pour un enfant aujourd'hui 1.01 est une notation raccourcie pour écrire 1 + 1/100=101/100.
http://circ-andelys.spip.ac-rouen.fr/spip.php?article258
Bref, un élève de CM1 commence par faire des calculs du genre 2/3 pour lesquels sa calculatrice donne un résultat faux ! Jette t-il pour autant sa calculatrice ? Non, car on lui apprend que 2/3 ne peut pas se représenter correctement en machine. Ensuite, il fait des calculs avec des fractions décimales, et sa machine donne parfois un résultat exact mais le plus souvent un résultat faux (sauf dans quelques cas rares liés au quotidien).
Quand il touchera à Python, il se dira, s'il a compris ce qu'on lui a dit, que tout comme sa machine se trompe pour 2/3, python se trompe pour 1/10 + 2 / 10, ce qui n'a absolument rien de surprenant.

Il n'a donc aucune raison, vu la conception qu'on lui enseigne, de s'étonner que quand on manipule des fractions (décimales ou pas), la machine donne dès le tout début de son apprentissage des résultats faux. C'est pour ça que je dis qu'il s'agit ici d'une obsession du décimal liée à une mauvaise conception de ce que sont les nombres.
- [^] # Re: Que disent les programmes du primaire
  
  Posté par C138 le 10 janvier 2018 à 16:30. Évalué à 0.
  
  «liée à une mauvaise conception de ce que sont les nombres.»
  
  … dans les machines.
  
  Parce que les nombres 0.2, 0.4 et 0.6, «en eux-mêmes» permettent bien d'écrire l'égalité : 0.2+0.4=0.6
  
  NB : Je note que, bien que la discussion porte initialement sur des 0.xxxx "finis", on se ramène systématiquement à évoquer les 1/3, 2/3 et cie, ce qui n'est pas exactement le même problème. On remplace l'obsession du décimal /fini/ (qui se traite intuitivement bien /sans machine/) par l'obsession du décimal /infini/ (qui effectivement pose problème [machine ou non]).
  
  Pour l'étude des programmes d'enseignement, rien à redire, les classes primaires ont été évoqués bien en amont dans ce fil (probablement pour évoquer la simplicité intuitive des calculs demandés et non pas la réalité pédagogique de la chose).
  - [^] # Re: Que disent les programmes du primaire
    
    Posté par snowball (site web personnel) le 10 janvier 2018 à 17:27. Évalué à 3.
    
    «liée à une mauvaise conception de ce que sont les nombres.»
    … dans les machines.
    
    Non, je veux vraiment dire "dans les têtes de ceux qui pratiquent les maths !"*
    
    ", bien que la discussion porte initialement sur des 0.xxxx "finis","
    
    C'est bien ce que je disais: c'est un problème de compréhension des nombres.
    
    Car 0.2345 est une notation raccourcie pour écrire une… fraction décimale ! En l'occurrence 2345/10000. C'est donc une fraction toute bête (enfin, plus compliquée que 1/3 quand même).
    
    Dire que ce décimal, c'est à dire cette fraction, est finie n'a aucun sens. (j'ai bien vu que tu avais mis des guillemets mais malgré tout, on voit là la confusion qui règne). C'est le développement en base 10 qui est fini. Dans une autre base, le développement sera différent et ne sera plus forcément fini. Ce n'est pas une propriété intrinsèque du nombre mais une propriété liée au choix d'une base. Ce problème de conception est le fil conducteur du journal en fait.
    
    Pour l'étude des programmes d'enseignement, rien à redire, les classes primaires ont été évoqués bien en amont dans ce fil (probablement pour évoquer la simplicité intuitive des calculs demandés et non pas la réalité pédagogique de la chose).
    
    Évoquées peut être, mais pour dire des choses fausses très souvent. Dans la discussion, certains ont avancé que 0.1 + 0.2 était un calcul de CE2. Or ce n'est pas du tout comme ça dans la réalité. C'est un calcul de CM2 qu'on fait après avoir découvert les rationnels et ça change absolument tout. En effet, ceux qui ont appris les maths dans cet ordre seront très probablement surpris de l'importance que tu accordes aux fractions décimales et pas aux autres (comme si elles avaient un intérêt supérieur aux autres fractions et qu'il faille absolument, juste pour elles, des résultats exacts avec une machine !).
    
    Dans les petites classes, les professeurs qui utilisent la calculatrice, font d'abord des calculs avec les fractions et les élèves, dès leurs premiers calculs (genre 2/3) voient qu'une calculatrice fait des approximations pour écrire les résultats et ne donne que très rarement un résultat juste. Les élèves voient donc les erreurs de la calculatrice même pour leurs tout premiers calculs. Le résultat donné par Python n'aura donc rien de surprenant pour eux puisque c'est ce qui s'est passé dès le début de leur utilisation de la calculatrice.
    
    Comprends-tu que si tu "exiges" de l'exactitude sur les calculs avec les fractions décimales du type $\frac{n}/{10^k}$ (les décimaux) alors que tu ne l'exiges pas sur des fractions plus "simples" du type 2/3, c'est uniquement parce que tu accordes une importance étrange aux décimaux (liée certainement à la façon dont on a présenté les nombres dans ton parcours scolaire). C'est pour ça que je parle de problème de conception des nombres pour ceux qui trouvent étrange ce qui se passe avec les floats. Ce sujet n'est pas vraiment un problème informatique, mais un problème lié à des conceptions mathématique biaisées par un apprentissage qui a focalisé inutilement sur les décimaux (en gros les générations qui ont fait un CM1 avant 2008).
  - [^] # Re: Que disent les programmes du primaire
    
    Posté par snowball (site web personnel) le 10 janvier 2018 à 17:49. Évalué à 2.
    Si tu veux que python ait le même comportement qu'une calculatrice, il suffit d'écrire une fonction ad hoc den utilisant un code de troncature du genre (pour des résultats sur douze chiffres):
```
Python 3.6.4 (default, Dec 23 2017, 19:07:07) 
[GCC 7.2.1 20171128] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print ("%.12f" % (0.1+0.2))
0.300000000000
```
    Python donnera ainsi des résultats arrondis du même type que la calculatrice (comme le font les tableurs et autres). Attention, on perdra du coup de la précision sur presque tous les calculs sauf, en apparence, pour ceux que tu juges "élémentaires".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.