snowball a écrit 168 commentaires

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 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 ;)

Voilà, on a fait le tour. Je ne peux plus rien pour toi. Amuse toi bien.

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.

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.

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 ?

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….

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 !!!!

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à.

Ç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.

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 à , 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.

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 ?".

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.

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.

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.

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é.

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.

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).

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).

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.

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 (mais pas 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.

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.

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.

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.

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 ).

Mais tu m'as dit que tu voulais non seulement faire des + ou des - mais aussi des 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 à  ?? 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.

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 et ). (Tu es bien d'accord que est un décimal puisqu'il vaut avec 98 zéros)

Eh bien, je vais te démontrer que ça n'est pas possible.

En effet, lorsque tu vas calculer tu voudrais que ça affiche un résultat correct c'est à dire mais ça n'est pas possible car la valeur minimale positive est .

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 à ).

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).