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 10^{-99} (mais pas 10^{-17} 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.
[^] # Re: Rien de surprenant
Posté par snowball (site web personnel) . En réponse au journal [Humour] vers un monde différent. Évalué à 4.
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 10^{-99} (mais pas 10^{-17} 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.