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 snowball (site web personnel) . En réponse au journal [Humour] vers un monde différent. Évalué à 6.
Mais tu n'as toujours pas lu que ce n'est pas vrai ??? La preuve:
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à...
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.
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.
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).
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.
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.