Bug Numbers : Somme non nulle

antro

Membre actif
24 Février 2008
973
23
53
31
:confused::confused::confused:

Alors là, je ne comprends pas très bien ce que me fait Numbers:


80e162b88514b304997ead90641841cb.png


C'est quoi ce 5,68434e-14, chez moi la somme des lignes en dessous, ça fait 0, point barre.
Bon certes, 5e-14 ça ne fait pas beaucoup, mais là, quand même, il n'y a pas photo, ça devrait faire 0! (Surtout que les autres chiffres du dessous ne sont pas des calcul d'autre chose, mais bien des chiffres que j'ai rentré moi même à la main.

Une idée ???
 
Bonsoir

Aussi surprenant que cela puisse paraître, ce type de résultat n'est pas foncièrement anormal. C'est un problème de mathématiques et de représentation numérique.

En effet, sur les microprocesseurs de nos ordinateurs (Mac ou PC) les nombres décimaux sont généralement représentés en interne sous la forme d'une mantisse et d'un exposant, tous deux exprimés sous forme binaire (i.e. en base 2). Or, les nombres qui apparaissent avec une partie décimale finie en base 10 ne possèdent pas forcément de représentation exacte dans ce système.

Par exemple, un nombre aussi simple que 0,2 s'écrit en binaire :
Bloc de code:
[0,001100110011...]
avec une infinité de bits après la virgule. On se retrouve avec le même soucis que des nombres comme 1/3 (≈ 0,333333...) en base 10 : on ne peut en donner qu'une représentation approchée, et par conséquent inexacte, parce qu'on est bien obligé de le tronquer à un endroit donné.

Dans ton exemple, les nombres 735,43 et -235,43 posent tous deux ce type de problème. En effet, l'ordinateur les représente respectivement par :
Bloc de code:
[1,011011111011011100001010001111010111000010100011110...] x 2^[1001]
–[1,110101101101110000101000111101011100001010001111011...] x 2^[111]
Ces représentations tronquées constituent des arrondis (à des valeurs supérieures ou inférieures selon le cas), ce qui peut avoir ensuite des répercutions dans les calculs.

Et le calcul que tu effectues isole justement les différences dus aux arrondis, puisqu'il tend à obtenir un résultat théoriquement nul par addition/soustraction de ces nombres : les valeurs exactes disparaissant dans le calcul, et il ne reste finalement plus que les erreurs (qui s'élèvent dans ton cas à –5,68434 x 10^–14).

:p

Tout ça pour te dire que Numbers et ton Mac fonctionnent très bien, mais que le calcul numérique sur ordinateur réserve quelques surprises que l'utilisateur se doit de savoir interpréter.
 
Bonsoir

Aussi surprenant que cela puisse paraître, ce type de résultat n'est pas foncièrement anormal. C'est un problème de mathématiques et de représentation numérique.

… (excellent exposé :zen:)

Mais tout ça n'apporte pas la solution (simple) au problème de notre ami, qui consiste, lorsqu'il manipule des sommes d'argent, à utiliser un format de cellules numériques à deux décimales (ce qui rendra, en outre son tableau plus lisible) :

number1.jpg
number2.jpg

Funny, is'nt it ? :D

Edit : cela dit, dans ce cas de figure précis, Excel est bien plus malin que Numbers, parce que lui, il sait détecter l'erreur et l'éliminer sans utiliser d'artifice d'affichage ! :

number3.jpg
 
Bonsoir

Aussi surprenant que cela puisse paraître, ce type de résultat n'est pas foncièrement anormal. C'est un problème de mathématiques et de représentation numérique.

Certes, je comprends.
Maintenant, allez expliquer ça à Mme Michu (qui n'a même pas eu son bac) et qui a acheté un Mac parce qu'on lui a dit que c'était plus facile d'utilisation et à qui on tente d'expliquer la représentation binaire de nombres décimaux pour justifier que dans son calcul elle a autre chose que 0 marqué dessus.. :rateau:
Moi, je suis désolé, mais j'appelle ça un bug...

OK, avec l'utilisation de format monétaire, ça passe mieux, mais quand même.....
 
Maintenant, allez expliquer ça à Mme Michu (qui n'a même pas eu son bac) et qui a acheté un Mac parce qu'on lui a dit que c'était plus facile d'utilisation et à qui on tente d'expliquer la représentation binaire de nombres décimaux pour justifier que dans son calcul elle a autre chose que 0 marqué dessus.. :rateau:
Moi, je suis désolé, mais j'appelle ça un bug...

Certes, mais là, je ne vois pas le rapport avec un Mac :heu: :confused:

Ça n'est pas parce qu'un logiciel est fait par Apple que le Mac ou Mac OS a quelque chose à y voir !
 
Moi, je suis désolé, mais j'appelle ça un bug...
Tout d'abord, ce n'est pas un problème du logiciel, mais un fonctionnement inhérent aux microprocesseurs issu d'un fait mathématique. D'ailleurs on rencontre aussi ce problème d'arrondi sur les petites calculatrices à quatre opérations, avec parfois des résultats encore plus aberrants.


Ensuite, le calcul numérique n'est pas une science facile, et il n'est pas possible d'obtenir exactement le résultat escompté par l'utilisateur lorsque l'intention de ce dernier n'est pas clairement exprimé : dans le cas du tableur, la présence d'un nombre dans une case constitue une bien maigre indication... à moins par exemple de spécifier un format monétaire, ce qui règle d'ailleurs ici le problème.

Il existe bien des moyens techniques pour régler automatiquement le soucis qui apparaît dans ce cas particulier, mais ils ne font que déplacer le problème (c'est par exemple le cas dans Excel). L'erreur n'apparaîtrait plus ici, mais ailleurs, dans d'autres situations. Parmi tous ces moyens, ceux qui donnent les meilleurs résultats ne sont néanmoins pas non plus parfaits, et ils s'avèrent généralement beaucoup plus coûteux en temps de calcul ou en moyens matériels. Il fallait bien trouver un compromis, et finalement les techniques mises en oeuvres ici sont probablement les meilleures, parce que les plus efficaces et les plus rentables, même si elles ne plaisent pas à tout le monde.


Enfin, si Mme Michu veut conduire une voiture, elle doit apprendre certains comportements de base ou bien connaître les lois de la physique qui régissent son véhicule, sinon elle risque de faire des tonneaux dans le premier virage serré négocié à trop grande vitesse.

De la même manière, si Mme Michu veut faire faire du calcul numérique à une machine, elle se doit d'en connaître les principes, sinon elle s'expose à des déconvenues.


La seule échappatoire à cette problématique inextricable est de toujours soumettre systématiquement les résultats obtenus à son analyse critique. Ne pas le faire suggèrerait que la machine est plus intelligente que soi, ce qui n'est normalement pas le cas.

Bref, comme dans tous les domaines techniques, il faut utiliser son intelligence pour exploiter ses outils qui sont, quoi qu'il en soit, toujours imparfaits.


_______________________________________________
« Science sans conscience n'est que ruine de l'âme »
 
De la même manière, si Mme Michu veut faire faire du calcul numérique à une machine, elle se doit d'en connaître les principes, sinon elle s'expose à des déconvenues.

Sauf que Mme Michu avec sa calculatrice à 5€, elle fait 735,43 - 500 - 235,43 et elle lui répond 0 !
Alors que son ordi à 1000€ + Numbers à 79€, il lui répond "-5,68434E-14". Comment je lui explique à ma grand mère ?


Au passage, même en forçant à 2 decimales, il me répond toujours "-5,68434E-14"?
Bizarre bizarre...

Et autre bizarrerie, en forçant en format monétaire, il me répond '-0.00€ "


PS: Je suis ingénieur en informatique à la base, et le coup de l'analyse critique, suis bien armé pour l'avoir, vu le rabâchage à longueur de journée de ma prof d'analyse numérique pendant mes études.
Sauf que sur une addition simple à 2 décimales je m'attendais franchement à un autre type de résultat ! C'est quand même surprenant !
 
Maintenant, allez expliquer ça à Mme Michu (qui n'a même pas eu son bac)

Ça m'étonnerait que Mme Michu utilise un tableur pour gérer ses comptes.

D'autant plus qu'il existe des logiciels dédiés gratuits (ou très peu chers).

On utilise un tableur lorsqu'on n'est pas satisfait de ce que proposent les logiciels existants.

Et dans ce cas, on doit prendre en compte la difficulté qu'implique l'exercice.

[Edit]: Après avoir lu ta dernière intervention, je suis stupéfait qu'un "ingénieur en informatique à la base" profère de tels propos (tu n'as sans doute pas écouté suffisamment le "rabâchage" de ta prof :confused:).
 
Je reçois et comprends parfaitement les discours, mais avouez franchement que sur une bête additions de 3 nombres à 2 chiffres après la virgule, on ne s'attend quand même pas à ça comme résultat !
Et le fait de devoir flanquer une explication sur la représentation binaire des nombres décimaux pour expliquer qu'une somme de 3 chiffres à 2 décimales ne tombe pas sur 0, c'est quand même un peu limite ! Tout le monde n'a pas un esprit scientifique et ne va pas comprendre le discours ! C'est quand même pas à la portée du commun des mortels de comprendre ça....
 
sur une bête additions de 3 nombres à 2 chiffres après la virgule, on ne s'attend quand même pas à ça comme résultat !

Pourtant PASCAL t'a déjà expliqué comment est obtenu ce résultat un peu étrange.

Un ingénieur en informatique devrait comprendre ses explications.

Il l'a expliqué très en détail et avec un raisonnement très clair dès ce matin.

J'imagine que dans Numbers (que je ne connais pas) comme dans Excel il suffit de formater les cellules pour éviter qu'apparaisse ce genre d'aberration.

C'est ce que proposait Pascal 77.

On ne va quand même pas passer le réveillon là dessus ;).
 
On ne va quand même pas passer le réveillon là dessus ;).

Ben si, justement, je compte organiser une soirée dédiée à cette question le 24 prochain, le premier qui parlera d'autre chose sera banni deux ans ! :p

:D

Bon, sérieusement, bien que tenant tout à fait la route, l'explication de PA5CAL n'est pas une justification en soit, ainsi que je l'expliquais plus haut, Excel, par exemple, ne succombe pas à cette imprécision, et donne le résultat correct (zéro), même sans appliquer quelque format que ce soit à la cellule, contrairement à Numbers, qui, même en utilisant ma "ruse" donne lui "-0,00" (moins zéro virgule zéro zéro). En matière de développement, c'est ce qu'on appelle un "cas limite", qui justifie une routine de correction, et considérer ça comme un bug n'est pas exagéré.
 
Bon, sérieusement, bien que tenant tout à fait la route, l'explication de PA5CAL n'est pas une justification en soit, ainsi que je l'expliquais plus haut, Excel, par exemple, ne succombe pas à cette imprécision, et donne le résultat correct (zéro), même sans appliquer quelque format que ce soit à la cellule, contrairement à Numbers, qui, même en utilisant ma "ruse" donne lui "-0,00"

Je suis d'accord, l'explication tiens bien la route et est très claire, sauf que même avec '-0.00€', à ma belle mère, je suis bien obligé de lui expliquer que c'est un bug et qu'elle devrait plutôt prendre Excel si elle ne veut pas avoir ce genre de surprise.

<Mode Hors Sujet>
Pis comme vous dites, on ne va pas passer le réveillon, on va juste passer de Numbers à Excel (ou OpenOffice à voir) pour éviter qu'elle ne se pose trop de questions.
Et je la voit déjà arriver "Oh ben non, mois j'utilise pas Numbers parce que ça bugge sur les additions"...
Et encore, j'aurai du bol si elle ne dit pas "Mon mac il bug, il ne sait même pas faire une addition".
Pis là, on pourra toujours y aller sur les explications des représentations binaires, parce que ma belle mère, elle sait aussi bugger quand elle veut !
</Mode Hors Sujet>


Allez, on arrête là sinon ça va virer au troll cette affaire... :rateau:

@Pascal 77, tu peux peut être fermer le sujet avant que ça ne dégénère ???
 
Juste je veux être présent pour le réveillon du 24 sur ce sujet&#8230;
 
Pour achever de perturber la belle-mère d'Antro, rappelons qu'Excel a aussi connu quelques bugs liés à la précision (en particulier "le" bug d'Excel 2007) et qu'on trouve une fiche complète pour traiter de ces aspects sur la KB de Microsoft (voir en particulier, en bas de page, la partie "Exemple lorsqu'une valeur atteint zéro").

Pour le réveillon, je peux amener du foie gras... ;)
 
Pour info, le tableur d'AppeWorks présente aussi l'erreur d'arrondi. [cf PJ à gauche]


Quant à celui d'OpenOffice (et je pense que c'est peut-être pareil pour Excel), il se contente par défaut d'arrondir de lui-même au deuxième chiffre après la virgule, comme dans le format monétaire. [cf PJ au milieu]

Le problème qui apparaît alors, c'est que lorsqu'on ajoute 0,005 à la somme prise ici pour exemple, le tableur présente toujours zéro au lieu du 0,005 attendu. On obtient donc un résultat faux. [cf PJ à droite]

C'est ce à quoi je faisais allusion en disant que les solutions ne faisaient que déplacer le problème.


Toute la question est de savoir si l'on veux faire plaisir à Mme Michu en lui présentant un résultat propre quand elle fait ses comptes, ou si l'on veut fournir un résultat avec une erreur interprétable au technicien qui tente de réalise son projet sans se tromper.


(À ce propos, il faudrait inviter Mme Michu au réveillon, je pense qu'avec tous ses soucis, la pauvre le mérite bien...)
 
Toute la question est de savoir si l'on veux faire plaisir à Mme Michu en lui présentant un résultat propre quand elle fait ses comptes, ou si l'on veut fournir un résultat avec une erreur interprétable au technicien qui tente de réalise son projet sans se tromper.

En l'occurence, pour Mme Michu, c'est l'option numéro 1.
Après il faudrait peut être un mode "expert" ou "raw" dans le tableur pour travailler plus "techniquement" sur des valeurs non traffiquées.
Efin, je ne pense pas me tromper en prenant l'hypothèse que la grande majorité des utilisateurs de tableurs qui font des calculs sont plutôt d'ordre "financier" pour lesquels un résultat propre est quand même plus "clean" qu'un résultat devant être analysé...

En tout cas, je n'irai pas moi non plus expliquer l'algèbre binaire et la représentation binaire des décimaux à mon contrôleur de gestion favori... (J'ai déjà bien assez de soucis comme ça avec lui ! ;)

Bon, d'un autre côté, je peux toujours m'en servir comme excuse : "Ben non, regarde, ton tableur il calcul faux...."

(PS: Le contrôleur de gestion c'est le mari de Mme Michu...)