Quand on pense que c'est... - Page 2

C'est clairement un choix de performance. Si on calcule avec des flottants binaires, on peut toujours avoir ce problème. La seule manière de l'éviter est de calculer tout en BCD comme le fait AMS. (C'est probablement ce que font Maxima et co., à moins que le résultat ne soit correct que "par hasard", parce qu'ils ont choisi une longueur de flottant différente qui fait que l'erreur "tombe" du bon côté.) La représentation rationnelle n'est pas une solution générale, elle marche ici, mais dès que tu appliques une fonction non-élémentaire, le résultat ne sera en général plus rationnel.

Je trouve ça vraiment trompeur, ça n'est vraiment pas le genre d'outil où je me serais attendu à voir surgir des problèmes de flottants, à moins que ça ne soit clairement indiqué de façon visible à côté du résultat, et quand bien même je pense avoir une compréhension raisonnable de la façon dont les erreurs de conversion binaire/décimal arrivent.

Uther (./29) :
A priori c'est correct si on part du principe que ceil(7,0000000000000009) fait bien exactement 8.

Mais ce n'est pas ce que j'ai donné comme entrée au système

On pourrait éventuellement dire que ça fait 8.0 pour signaler que le résultat provient d'une valeur approchée. Mais si on fait un ceil, c'est généralement parce que l'on veut retomber sur des valeurs exactes et au final ça ne changerait pas l’écart.Bref en mathematica comme en programmation, les flottants c'est le bordel, et mieux vaux ne pas les utiliser à mois d'y être contraint et de savoir exactement ce que l'on fait.

Les flottants ont des règles très précises.

Zerosquare (./21) :
Même parmi mes collègues développeurs, la majorité comprend très mal voire pas du tout le fonctionnement des nombre flottants binaires. Alors si le profil des utilisateurs est plutôt orienté mathématique il y a fort a parier qu'il ne comprendront pas ce qui se passe.

Le problème est juste de comprendre que le nombre en représentation décimale est arrondi en représentation flottante avant même toute opération sur le nombre. Et il faut savoir les nombres qui sont représentés exactement. Après çà ce n'est pas très compliqué.

Kevin Kofler (./31) :
Si on calcule avec des flottants binaires, on peut toujours avoir ce problème. La seule manière de l'éviter est de calculer tout en BCD comme le fait AMS.

Pas forcément. Et de toute façon, même avec les BCD, tu ne peux pas représenter exactement les division par 3. Ce qu'il faut surtout faire c'est maitriser l'erreur commise et sa propagation.

Est-ce qu'on peut l'éviter en faisant convertir au logiciel tout flottant fini par une division par 10ⁿ pour un nombre multiplié par 10ⁿ ?

Qu'une entrée ou résultat de 159.7884 soit remplacé par 1597884/10000 ?
Et que pour les flottants très longs ou indéfinis, le facteur n soit limité à la précision que le logiciel donne au résultat ?

Zerosquare (./30) :
Tiens, j'aurais plutôt dit que les "matheux" seraient plus susceptibles de comprendre les flottants et les problèmes associés que les "dévs" : quand on creuse, c'est quelque chose de beaucoup plus proche des mathématiques "pures" que de l'info appliquée. Mais je ne sais pas si ceux qui ont un cursus "matheux" sont familiarisés à ces questions (en 2016, avec des ordinateurs partout, on pourrait l'espérer, mais...)

Je ne doute pas qu'ils aient les capacités intellectuelles de comprendre la chose. C'est juste qu'il ne sont pas habitués a travailler en binaire, et surtout ils ne s'imaginent pas naturellement qu'un nombre écrit de manière décimale est en fait binaire.

PpHd (./33) :
Les flottants ont des règles très précises.

Je dirais au contraire que l'implémentation de float est plutôt variable, malgré le IEEE 754 qui plus ou moins bien implémenté par chaque langage.
En tout cas le comportement observé ici est tout a fait cohérent avec les règles habituelles des flottants binaire.

PpHd (./33) :
Le problème est juste de comprendre que le nombre en représentation décimale est arrondi en représentation flottante avant même toute opération sur le nombre. Et il faut savoir les nombres qui sont représentés exactement. Après çà ce n'est pas très compliqué.

Il y a deux problèmes : les arrondis suite a certains calculs comme la division, et les arrondis dus à la conversion binaire/décimal (qui peuvent être en effet evités par du BCD).
Les premiers sont assez naturels : on apprend a les gérer dès l'école primaire. Pour les seconds c'est pas du tout naturel pour quelqu'un qui ne connaît pas le problème. En général seul les développeurs connaissent bien le soucis, et encore pas tous.
C'est pour ça que je pense que les flottants dans ce genre de logiciel est probablement une mauvaise idée, même

Meowcate (./34) :
Est-ce qu'on peut l'éviter en faisant convertir au logiciel tout flottant fini par une division par 10ⁿ pour un nombre multiplié par 10ⁿ ?
Qu'une entrée ou résultat de 159.7884 soit remplacé par 1597884/10000 ?

Oui, ça sera mois performant mais exact.

Meowcate (./34) :
Et que pour les flottants très longs ou indéfinis, le facteur n soit limité à la précision que le logiciel donne au résultat ?

Ça serait sans doute plus compliqué: en fonction de l’enchaînement des opérations demandées la précision nécessaire des entrées peut varier.

Uther (./35) :
Je ne doute pas qu'ils aient les capacités intellectuelles de comprendre la chose. C'est juste qu'il ne sont pas habitués a travailler en binaire, et surtout ils ne s'imaginent pas naturellement qu'un nombre écrit de manière décimale est en fait binaire.

Vue l'omniprésence des outils informatiques, c'est quand même une sacrée lacune. Je leur jette pas la pierre, dans mon école d'ingénieur y'avait aucun cours sur l'analyse numérique (enfin y'avait peut-être une option là-dessus en dernière année, mais rien en tronc commun). Mais ça aurait probablement demandé de faire sauter une matière bidon pour la remplacer par des trucs utiles, ce qui était clairement inacceptable.

À l'Université de Vienne (Autriche), l'analyse numérique est une matière obligatoire pour les études de Mathématiques.