Quelle est la meilleure façon d'expliquer le problème d'arrondi à virgule flottante aux clients ?

je sais

http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html

ainsi que les entrées dans la FAQ C ++ et diverses autres pages destinées aux développeurs et aux scientifiques, mais existe-t-il une page Web, un article ou une explication, destiné aux clients "réguliers" avec une formation mathématique ou scientifique limitée? (pour lesquels les références ci-dessus tombent à plat).

Si elle était maintenue ou provenait d'une institution ou d'une société bien connue et reconnue, tant mieux, étant donné que, comme certains d'entre vous l'ont peut-être vécu, il peut être un peu compliqué de l'expliquer vous-même.

Je trouve qu'un moyen simple d'expliquer cela est de le démontrer . Discutez de la façon dont la division xpar un nombre, puis la multiplication par le même nombre devraient vous ramener à xnouveau - amenez le client à accepter que cela devrait toujours être le cas. Faites ensuite l'ancien (100 / 3) * 3sur une calculatrice; montrer que la valeur ne retourne pas à 100, comme vous vous en doutez, lorsque la plupart des gens voient des mathématiques apparemment simples "s'effondrer", puis ont tendance à "prendre" le risque de nombres à virgule flottante où la précision est importante (bien que dans une approche intuitive plutôt qu'au niveau bas dans lequel l'article que vous pointez va).

Malheureusement, la plupart des calculatrices à moitié décentes (certainement toutes les calculatrices scientifiques que j'ai vues et plus que quelques-unes de base) sont capables de gérer cela aujourd'hui - je suppose qu'elles stockent des chiffres supplémentaires au-delà de ce qui peut être affiché et arrondi - alors faites-le vérifiez à quel point votre calculatrice est intelligente avant de le faire devant votre client.

Je ne pense pas qu'il y ait de raccourcis. Vous devez soit:

• Comprenez ce qu'est la virgule flottante et comment elle se comporte.

Ou, si cela est trop exigé, vous devez simplement:

• Acceptez que l'ordinateur ne vous donne pas de résultats numériques exacts.

Peut - être un exemple avec des nombres irrationnels aide (même si les problèmes de virgule flottante appliquent aux nombres rationnels ainsi): sqrt(2) ~ 1.414. Alors 1.414^2 = 1.999396. Peu importe le nombre de chiffres que vous prenez, vous ne reviendrez jamais tout à fait à l'original 2. Ok, 4 chiffres significatifs corrects peuvent être acceptables, mais réfléchissez à ce qui se passe lorsque ce type d '"erreurs d'arrondi" s'accumule. C'est là que se trouve le vrai danger.

Tout d'abord, déterminez de quoi ils se plaignent. Les transactions financières doivent être effectuées avec précision, avec le bon nombre de décimales et les bonnes règles d'arrondi. Cela signifie généralement maintenir des nombres entiers d'unités monétaires et s'assurer que l'arithmétique est bien faite.

Alternativement, ils peuvent se plaindre d'affichages surexactes et réduire le nombre de chiffres significatifs en sortie peut être tout ce qui est nécessaire.

Pour les nombres en général, vous pouvez toujours essayer de trouver un x décimal à trois chiffres tel que x * 3 soit 10. Cela montre les principes de base.

Il reste deux problèmes. La première est que certains nombres peuvent être exprimés exactement en décimal mais pas en binaire (3,15, par exemple). Cela va être difficile à expliquer aux personnes non techniques, et votre meilleur pari est d'essayer de l'éviter en ne fournissant pas suffisamment de chiffres significatifs pour qu'il apparaisse. L'autre est le client qui en sait un peu, assez pour savoir que l'arithmétique informatique n'est pas toujours exacte et pas assez pour réaliser que l'arithmétique décimale n'est pas toujours exacte. J'en ai discuté avec quelques-uns et je n'ai rien d'utile à signaler.

Les nombres à virgule flottante dans les ordinateurs utilisent le binaire, donc tout comme nous avons un système de nombres avec des colonnes un, des dizaines, des centaines et des dixièmes, des centièmes, les nombres à virgule flottante dans les ordinateurs ont en fait un, deux, quatre et deux moitiés, des quarts et huitièmes colonnes. Si le client est familier avec les pieds / pouces, rappelez-lui comment vous utilisez généralement les fractions de base 2 d'un pouce pour la mesure.

Essayez maintenant de stocker 10 cents comme une combinaison de moitiés, trimestres, huitièmes de dollar. Cela ne fonctionne tout simplement pas:

.00011001100110011. . . (se répète à l'infini )

C'est la même chose que de prendre un ruban à mesurer impérial standard et d'essayer de mesurer un dixième de pouce. Vous ne pouvez pas le faire avec précision. Il n'y a pas de représentation de 1/10 comme X / Y où X et Y sont des nombres entiers et Y est une puissance de 2.

C'est pourquoi nous avons les types de données décimaux qui utilisent 4 bits pour stocker chaque chiffre décimal , nous sommes donc de retour à la représentation en base 10. Le compromis est dans l'espace et la performance (environ 100% de performance, d'après ce que j'ai lu).

Dites-leur que, tout comme leur compte bancaire ne peut pas contenir 4,4423425908459032890413 ... dollars (c'est soit 4,44 $ soit 4,45 $, rien entre les deux), l'ordinateur ne peut pas facilement stocker un numéro avec une précision arbitraire. Les imperfections de stockage conduisent à des imperfections de calculs.

(Il triche légèrement, mais devrait leur donner une idée du problème.)

2/3

Demandez-leur d'écrire la réponse exacte à deux divisée par 3.
Puisque la réponse «continue pour toujours», vous pouvez le signaler.

L'utilisation de 1/3 fonctionnerait également, mais 2/3 est peut-être un meilleur exemple car l'arrondi vous donne (par exemple) .6666667 alors que .3333333 semble pouvoir être tronqué.

Lors des calculs, les ordinateurs utilisent généralement des approximations de nombres (comme plutôt que d'utiliser 1000000.7, ils utilisent 1000000) car l'utilisation d'approximations est beaucoup plus rapide. Le problème est que lorsque vous effectuez des calculs avec des approximations, vous obtenez des approximations. Habituellement, cela fonctionne assez bien, mais parfois cela conduit à des résultats inattendus.

Certains calculs sont effectués selon une règle légale. Par exemple, si vous souhaitez calculer le montant de l'impôt sur le revenu à payer sur un revenu annuel imposable de 79.245,18 € en Allemagne, il n'y a qu'une seule bonne réponse. Vous vous trompez ou vous vous trompez. Si vous avez raison, vous n'avez pas besoin d'expliquer le fonctionnement de l'arithmétique à virgule flottante. Si vous vous trompez, vous n'avez pas besoin d'expliquer comment fonctionne l'arithmétique à virgule flottante, vous devez corriger votre code cassé.

Parfois, vous affichez des résultats qui ne semblent pas corrects. Par exemple, si vous convertissez 13 297,46 $ US en UK £ avec deux chiffres décimaux, puis reconvertissez ce montant de UK £ en US $, vous pourriez ne pas obtenir 13 297,46 $ US mais 13 297,45 $ US ou 13 297,47 $ US. Cela n'a rien à voir avec l'arithmétique à virgule flottante. C'est un problème inévitable et vous feriez mieux de pouvoir expliquer pourquoi il est inévitable. (Vous devez également savoir pourquoi le problème ne se produit pas lorsque vous convertissez de UK £ en US $ et vice-versa).

Il existe d'autres résultats possibles qui ne semblent pas corrects. Si vous convertissez des nombres en pourcentages, les pourcentages doivent totaliser 100%, mais ils pourraient ne pas l'être. Si vous affichez quatre pourcentages avec deux décimales, les quatre pourcentages affichés peuvent totaliser 99,99% ou 100,01%. Rien à voir avec l'arithmétique à virgule flottante. Vous devriez toujours pouvoir expliquer pourquoi.

Ensuite, il existe des situations où l'utilisation imprudente de l'arithmétique à virgule flottante conduit à des résultats inappropriés. Par exemple, a + b + c n'est généralement pas identique à b + c + a. Si cela pose problème, il n'y a rien à expliquer, c'est quelque chose que vous corrigez.