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 snowball (site web personnel) . En réponse au journal [Humour] vers un monde différent. Évalué à 10.
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,
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 !
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....