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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -5.
Oui. Pour rappel, la sitaution actuelle, float, se vautre dès la première.
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)
Mon problème c'est pas l'affichage, c'est le calcul mathématique (tu sais le truc avec les anneaux).
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.
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.
1/3 c'est pas représentable en float non plus.
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.
Le SIDA c'est pas moi, je promets.
Non. Je veux (2.0 - 1.8 - 0.2 == 0.0) => True (ça aussi je l'ai dit et répété)
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)
Oui, et parce que ça va bcp plus vite. Je sais tout ça, t'inquiètes pas.
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.