«liée à une mauvaise conception de ce que sont les nombres.»
… dans les machines.
Parce que les nombres 0.2, 0.4 et 0.6, «en eux-mêmes» permettent bien d'écrire l'égalité : 0.2+0.4=0.6
NB : Je note que, bien que la discussion porte initialement sur des 0.xxxx "finis", on se ramène systématiquement à évoquer les 1/3, 2/3 et cie, ce qui n'est pas exactement le même problème. On remplace l'obsession du décimal /fini/ (qui se traite intuitivement bien /sans machine/) par l'obsession du décimal /infini/ (qui effectivement pose problème [machine ou non]).
Pour l'étude des programmes d'enseignement, rien à redire, les classes primaires ont été évoqués bien en amont dans ce fil (probablement pour évoquer la simplicité intuitive des calculs demandés et non pas la réalité pédagogique de la chose).
Quand je parle de même réaction, c'est pas tellement sur la surprise technique (une fois que les gens ont lu la norme bah ok, ça roule)
Ce qui surprend c'est l'aveuglement [ici, linuxfr] à envisager que la situation puisse choquer quand on la compare à l'intuition habituelle du problème. En gros des problèmes pour les très petites et grandes valeurs, ça ok, tout le monde le sait. Mais sur ce genre de calcul, devoir faire appel à une librairie «spécialisée» (!! ;-)
Mais je suis désolé, et ça va certainement choquer, ce que je veux calculer ce n'est pas «la vérité selon la norme machin qui me rappellera sans arrêt que 0.1 pose problème en binaire» (pas mon problème) mais la vérité mathématique du CE2 à la terminale et plus si affinité, quitte à ce que le logiciel me mente sur son «erreur» (je voulais dire comportement interne).
Ce qui m'intéresse c'est la vérité mathématique et pas la vérité IEEE. Du coups, il y a / aura effectivement un dilemme entre affichages et calculs internes.
Pour contextualiser un peu, j'en suis venu récemment à python (puis ce "problème") parce que Python va être enseigné de plus en plus en lycée. Bon, bah c'est simple : "Madame/Monsieur, votre truc marche pas, il ne sait pas calculer (calculs habituels décimaux) aussi bien que ma calculatrice"
Je vous laisse prendre la place des enseignants qui devraient donc sortir l'artillerie IEEE pour expliquer la situation… ;-)
Je comprends que l'ambiance se dégrade très vite ici. Je vais juste l'écrire paisiblement : commentaire inutile.
a) contexte mathématique numérique théorique et donc justement pas en implémentations informatiques "biaisées"
Donc, dans les bouquins de mathématiques, (une fraction x - une fraction x) = 0 , (un complexe x - un complexe x) = 0, et même (un ensemble x - un ensemble x) c'est l'ensemble vide (i.e. le "0" des ensembles).
Exception de valeurs particulière, données par B.Sibaud, qui avait bien compris/lu la remarque.
b) oui, et re-re-oui, on a tous compris l'explication mécanique. J'ai bien tout relu avant de commenter.
c) oui également, Decimal est effectivement un moyen de cacher/surcharger/contourner ce qui "tracasse"
d) exemple inutile. Pas d'étape pathologique inside. À comparer avec 0.2+0.4-0.6 et même avec 0.2-0.6-0.4, où l'erreur affichée n'est pas la même, non commutativité des calculs numériques [/ arrondis] bien connue également…
Fin, bref, ça tourne en rond, pour rien.
Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.
Perso je vois au moins trois implémentations arithmétiques "decimalo-flottantes" satisfaisantes (au sens naturel du terme)
* une simple calculatrice scientifique qui couvre correctement son domaine de fonctionnement (exact pour les décimaux usuels, notation ingénieur/scientifique ailleurs)
* bc, (An arbitrary precision calculator language) même caractéristiques
* le langage de Google, Go qui semble se comporter comme souhaité. (confirmation/infirmation ?)
Cela est donc bien possible. Que cela ne soit pas le choix de Python (et de bien d'autres langages), ben ok. Mais ça interpelle. C'est tout.
PS : Ah oui, en La(TeX) aussi c'est bon à première vue, 0.2+0.4 donne 0.60000 ;-)
PS2 : 4ème implémentation déjà évoquée, un tableur. Ça se comporte, suffisamment bien, que ce soit pour les décimaux que pour des valeurs grandes.
Me suis pris au jeu… de trouver des propositions simples et «satisfaisantes» (j'ai pas dit correctes ou incorrectes hein)…
Effectivement, pas grand chose en dehors de bc.
Même Perl est une illusion car même si
echo "print(0.2+0.4)" | perl donne bien 0.6
echo "print(0.2+0.4-0.6)" | perl donne 1.11022302462516e-16 et non pas le tant espéré 0…
Bref, je viens de tomber sur un langage que ce petit test (heuristique oui) ne met pas en défaut, ça se passe ici : https://golang.org/#
avec fmt.Println(0.2+0.4-0.6) ça donne bien 0
Ah oui, c'est vrai.
Mais ça reste maîtrisable dans une implémentation d'exclure ou plutôt de traiter spécifiquement ces valeurs.
Le code donné en est la preuve ;-)
Je viens de me créer un compte exprès pour ça.
Donc juste pour ajouter mon soutien (insignifiant, certes) à reynum…
Je suis tombé des mêmes nues en découvrant ce «détail» (et l'étendue des langages concernés).
Je vais pas faire long, mais juste pour dire qu'en diffusant cette info dans un contexte de labo, plutôt scientifique, développement logiciel (fiabilité et cie), j'ai les mêmes réactions.
En gros on nous explique que pour avoir les performances d'un avion de chasse, on ne pourrait plus voler comme un avion de lignes intérieures…
(Contexte perso : j'ai eu la même formation théorique que beaucoup ici visiblement, j'ai développé des outils d'analyse de langage/grammaire/typage plutôt sérieux, je comprends donc bien également les explications techniques mais j'exprime le même ressenti d'insatisfaction vis à vis de la situation)
PS : (cas particulier, certes) Pour ce qui est d'accepter que "a - a == un chouilla exprimé comme on veut", je ne peux m'empêcher de penser qu'un langage moderne est capable de détecter quand deux noms désignent le même objet et qu'il peut donc se dispenser d'appeler l'artillerie lourde soit-elle une norme internationale et retourner systématiquement 0, sans se poser de question.
[corollaire : dans quel contexte mathématique numérique théorique, x - x n'est pas zéro… ?]
Cela étant, ce fil de discussion est vraiment très très instructif mais certainement pas sur les aspects techniques ;-)
Merci à tous.
# Mediawiki avec stéroïdes
Posté par C138 . En réponse à la dépêche Un annuaire des producteurs locaux en Open-Source. Évalué à 2 (+2/-0).
Bonjour
(super projet ;-)
Suggestion : étendre mediawiki avec semanticwiki (ça change la vie)
Premier effet : cela transforme mediawiki en véritable base de données (requêtes, filtres, formulaires …)
https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki
Le mode d'extension dépend du mode d'installation du mediawiki (manuel, docker ou autres)
Bonne continuation
# Errreur sur le visionnage de la vidéo descriptive
Posté par C138 . En réponse à la dépêche Ubiquity, un logiciel de monitoring de travaux pratiques de développement informatique. Évalué à 0.
"Une erreur est survenue :Échec du chargement de la ressource.
Erreur : mediaError bufferStalledError"
[^] # Re: Que disent les programmes du primaire
Posté par C138 . En réponse au journal [Humour] vers un monde différent. Évalué à 0.
«liée à une mauvaise conception de ce que sont les nombres.»
… dans les machines.
Parce que les nombres 0.2, 0.4 et 0.6, «en eux-mêmes» permettent bien d'écrire l'égalité : 0.2+0.4=0.6
NB : Je note que, bien que la discussion porte initialement sur des 0.xxxx "finis", on se ramène systématiquement à évoquer les 1/3, 2/3 et cie, ce qui n'est pas exactement le même problème. On remplace l'obsession du décimal /fini/ (qui se traite intuitivement bien /sans machine/) par l'obsession du décimal /infini/ (qui effectivement pose problème [machine ou non]).
Pour l'étude des programmes d'enseignement, rien à redire, les classes primaires ont été évoqués bien en amont dans ce fil (probablement pour évoquer la simplicité intuitive des calculs demandés et non pas la réalité pédagogique de la chose).
[^] # Re: Commentaire de soutien ;-)
Posté par C138 . En réponse au journal [Humour] vers un monde différent. Évalué à 0.
Quand je parle de même réaction, c'est pas tellement sur la surprise technique (une fois que les gens ont lu la norme bah ok, ça roule)
Ce qui surprend c'est l'aveuglement [ici, linuxfr] à envisager que la situation puisse choquer quand on la compare à l'intuition habituelle du problème. En gros des problèmes pour les très petites et grandes valeurs, ça ok, tout le monde le sait. Mais sur ce genre de calcul, devoir faire appel à une librairie «spécialisée» (!! ;-)
Mais je suis désolé, et ça va certainement choquer, ce que je veux calculer ce n'est pas «la vérité selon la norme machin qui me rappellera sans arrêt que 0.1 pose problème en binaire» (pas mon problème) mais la vérité mathématique du CE2 à la terminale et plus si affinité, quitte à ce que le logiciel me mente sur son «erreur» (je voulais dire comportement interne).
Ce qui m'intéresse c'est la vérité mathématique et pas la vérité IEEE. Du coups, il y a / aura effectivement un dilemme entre affichages et calculs internes.
Pour contextualiser un peu, j'en suis venu récemment à python (puis ce "problème") parce que Python va être enseigné de plus en plus en lycée. Bon, bah c'est simple : "Madame/Monsieur, votre truc marche pas, il ne sait pas calculer (calculs habituels décimaux) aussi bien que ma calculatrice"
Je vous laisse prendre la place des enseignants qui devraient donc sortir l'artillerie IEEE pour expliquer la situation… ;-)
[^] # Re: Commentaire de soutien ;-)
Posté par C138 . En réponse au journal [Humour] vers un monde différent. Évalué à -3.
Je comprends que l'ambiance se dégrade très vite ici. Je vais juste l'écrire paisiblement : commentaire inutile.
a) contexte mathématique numérique théorique et donc justement pas en implémentations informatiques "biaisées"
Donc, dans les bouquins de mathématiques, (une fraction x - une fraction x) = 0 , (un complexe x - un complexe x) = 0, et même (un ensemble x - un ensemble x) c'est l'ensemble vide (i.e. le "0" des ensembles).
Exception de valeurs particulière, données par B.Sibaud, qui avait bien compris/lu la remarque.
b) oui, et re-re-oui, on a tous compris l'explication mécanique. J'ai bien tout relu avant de commenter.
c) oui également, Decimal est effectivement un moyen de cacher/surcharger/contourner ce qui "tracasse"
d) exemple inutile. Pas d'étape pathologique inside. À comparer avec 0.2+0.4-0.6 et même avec 0.2-0.6-0.4, où l'erreur affichée n'est pas la même, non commutativité des calculs numériques [/ arrondis] bien connue également…
Fin, bref, ça tourne en rond, pour rien.
Je le reformule également : en dehors d'un milieu geek "conditionné", le constat évoqué fait pour le moins sourire.
Perso je vois au moins trois implémentations arithmétiques "decimalo-flottantes" satisfaisantes (au sens naturel du terme)
* une simple calculatrice scientifique qui couvre correctement son domaine de fonctionnement (exact pour les décimaux usuels, notation ingénieur/scientifique ailleurs)
* bc, (An arbitrary precision calculator language) même caractéristiques
* le langage de Google, Go qui semble se comporter comme souhaité. (confirmation/infirmation ?)
Cela est donc bien possible. Que cela ne soit pas le choix de Python (et de bien d'autres langages), ben ok. Mais ça interpelle. C'est tout.
PS : Ah oui, en La(TeX) aussi c'est bon à première vue, 0.2+0.4 donne 0.60000 ;-)
PS2 : 4ème implémentation déjà évoquée, un tableur. Ça se comporte, suffisamment bien, que ce soit pour les décimaux que pour des valeurs grandes.
# À part bc
Posté par C138 . En réponse au journal [Humour] vers un monde différent. Évalué à 0.
Me suis pris au jeu… de trouver des propositions simples et «satisfaisantes» (j'ai pas dit correctes ou incorrectes hein)…
Effectivement, pas grand chose en dehors de bc.
Même Perl est une illusion car même si
echo "print(0.2+0.4)" | perl donne bien 0.6
echo "print(0.2+0.4-0.6)" | perl donne 1.11022302462516e-16 et non pas le tant espéré 0…
Bref, je viens de tomber sur un langage que ce petit test (heuristique oui) ne met pas en défaut, ça se passe ici :
https://golang.org/#
avec fmt.Println(0.2+0.4-0.6) ça donne bien 0
C'est peut-être le Println qui cache la forêt… ??
[^] # Re: Commentaire de soutien ;-)
Posté par C138 . En réponse au journal [Humour] vers un monde différent. Évalué à -1.
Ah oui, c'est vrai.
Mais ça reste maîtrisable dans une implémentation d'exclure ou plutôt de traiter spécifiquement ces valeurs.
Le code donné en est la preuve ;-)
# Commentaire de soutien ;-)
Posté par C138 . En réponse au journal [Humour] vers un monde différent. Évalué à -2.
Je viens de me créer un compte exprès pour ça.
Donc juste pour ajouter mon soutien (insignifiant, certes) à reynum…
Je suis tombé des mêmes nues en découvrant ce «détail» (et l'étendue des langages concernés).
Je vais pas faire long, mais juste pour dire qu'en diffusant cette info dans un contexte de labo, plutôt scientifique, développement logiciel (fiabilité et cie), j'ai les mêmes réactions.
En gros on nous explique que pour avoir les performances d'un avion de chasse, on ne pourrait plus voler comme un avion de lignes intérieures…
(Contexte perso : j'ai eu la même formation théorique que beaucoup ici visiblement, j'ai développé des outils d'analyse de langage/grammaire/typage plutôt sérieux, je comprends donc bien également les explications techniques mais j'exprime le même ressenti d'insatisfaction vis à vis de la situation)
PS : (cas particulier, certes) Pour ce qui est d'accepter que "a - a == un chouilla exprimé comme on veut", je ne peux m'empêcher de penser qu'un langage moderne est capable de détecter quand deux noms désignent le même objet et qu'il peut donc se dispenser d'appeler l'artillerie lourde soit-elle une norme internationale et retourner systématiquement 0, sans se poser de question.
[corollaire : dans quel contexte mathématique numérique théorique, x - x n'est pas zéro… ?]
Cela étant, ce fil de discussion est vraiment très très instructif mais certainement pas sur les aspects techniques ;-)
Merci à tous.