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.
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.
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.
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.
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.
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.
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.).
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.
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.
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.
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.
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.
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.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -4.
Je suis déçuuuuuuuuuuuu !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# comm
Posté par gUI (Mastodon) . En réponse au message Créer deux fichiers avec un seul grep. Évalué à 1.
Alors j'ai pas plus testé que ça, mais je crois bien que comm fait ça.
C'est sympa de voir le nb de solutions différentes au même pb :)
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) . En réponse au journal [Humour] vers un monde différent. Évalué à -1.
Je sais, mais ce n'est pas de ça dont je parle.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -2.
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).
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -4.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -3.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -1.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -2.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. É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: Back to the sixties
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. É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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. É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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. É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: Années 80
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -2.
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: Rien de surprenant
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -2.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -1.
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: C'est bien une erreur de la part de l'utilisateur !
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -2.
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: Rien de surprenant
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -3. Dernière modification le 19 décembre 2017 à 22:01.
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: Back to the sixties
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. É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: Rien de surprenant
Posté par gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. É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) . En réponse au journal [Humour] vers un monde différent. Évalué à -4.
Oui. On m'accuse de pas écouter les autres, mais j'ai l'impression que quand même on m'écoute pas trop.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. É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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -3. Dernière modification le 19 décembre 2017 à 19:44.
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.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -2.
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é.
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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. É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 gUI (Mastodon) . En réponse au journal [Humour] vers un monde différent. Évalué à -3. Dernière modification le 19 décembre 2017 à 17:59.
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.