arrondis.. bug d'Excel ?
- Initiateur de la discussion rodge5895
- Date de début
Staple1600
XLDnaute Barbatruc
Bonjour le fil, le forum
Merci pour ton lien, j'ai téléchargé le PDF de l'article
rodge5895
XLDnaute Occasionnel
Bonjour à tous
Finalement, on constate dans l’exemple de mon fichier joint en tête de ce fil :
1/ Que Excel sait faire une soustraction avec une réussite à 100% sur les lignes 3 et 8
2/ Qu’il présente un résultat faux sur les lignes 4 à 7 car présences d’arrondis inattendus, ce qui entraine à tort un message d’erreur indiquant un écart (colonne g) alors qu’il n’y en a bien sûr pas.
A vous lire, il existe une explication scientifique à cet écart (Excel est limité par la taille de son co-processeur CPU ( ???...), il a du mal à comprendre les nb divisés par 5 ( ???...), etc, etc… mais surtout, il ne s’agit pas d’un bogue !
Les érudits et autres experts d’Excel auraient-ils perdu leur sens de l’objectivité ?
Très simplement, je considère à mon niveau, outre le fait (et on est tous d’accord avec ça) qu’Excel est un tableur fabuleux, qu’il présente une faille sur la gestion de ses arrondis, explicable scientifiquement, alors qu’un enfant de classe de CM1 aurait donné la bonne réponse.
Ce qui marche à 10 chiffres après la virgule ne marche plus à 12 ou 15 chiffres.
Sauf à prouver dans l’exemple que 690.56 = 690.559999999999
Finalement, on constate dans l’exemple de mon fichier joint en tête de ce fil :
1/ Que Excel sait faire une soustraction avec une réussite à 100% sur les lignes 3 et 8
2/ Qu’il présente un résultat faux sur les lignes 4 à 7 car présences d’arrondis inattendus, ce qui entraine à tort un message d’erreur indiquant un écart (colonne g) alors qu’il n’y en a bien sûr pas.
A vous lire, il existe une explication scientifique à cet écart (Excel est limité par la taille de son co-processeur CPU ( ???...), il a du mal à comprendre les nb divisés par 5 ( ???...), etc, etc… mais surtout, il ne s’agit pas d’un bogue !
Les érudits et autres experts d’Excel auraient-ils perdu leur sens de l’objectivité ?
Très simplement, je considère à mon niveau, outre le fait (et on est tous d’accord avec ça) qu’Excel est un tableur fabuleux, qu’il présente une faille sur la gestion de ses arrondis, explicable scientifiquement, alors qu’un enfant de classe de CM1 aurait donné la bonne réponse.
Ce qui marche à 10 chiffres après la virgule ne marche plus à 12 ou 15 chiffres.
Sauf à prouver dans l’exemple que 690.56 = 690.559999999999
Bonsoir à tous ,
Je suis allé voir du côté de LibreOffice Calc. Il réagit différemment d'Excel.
Tous les écarts sont considérés comme OK alors que 3 d'entres eux ont manifestement des parties décimales différentes !
Pour ceux qui ont LibreOffice, ôter l'extension .txt pour ouvrir le fichier .ods.
,Je suis allé voir du côté de LibreOffice Calc. Il réagit différemment d'Excel.
Tous les écarts sont considérés comme OK alors que 3 d'entres eux ont manifestement des parties décimales différentes !
Pour ceux qui ont LibreOffice, ôter l'extension .txt pour ouvrir le fichier .ods.
Pièces jointes
Patrice33740
XLDnaute Impliqué
Comme tous les outils, Excel travaille avec une certaine précision, suffisamment grande pour un usage scientifique courant, mais on ne peut pas lui demander une précision supérieure à ses capacités.
Dans ton exemple, les nombres sont affichés avec 30 chiffres après la virgule alors que sa précision est de 15 chiffres significatifs, si tu te limites à 5 avant la virgule et 10 après (15 au total), et si tu utilises la précision affichée, ça fonctionne parfaitement !
Quand on utilise un outil, il faut apprendre à s'en servir correctement, c''est un peu comme le pèse-personne qui indique 75,3 kg avec une précision standard de 4%, soit + ou - 3 kg.
Dranreb
XLDnaute Barbatruc
Bonsoir.
0,001100110011001100110011001100110011001100110011001101
qui vaut en fait 3602879701896397 × 2^-54
soit à peu près 0,20000000000000001110223024625157
Excel a toutefois peut être une lacune au sujet des valeurs de cellules munies d'un format monétaire on comptable. Il semblerait qu'il triche en les stockant aussi en Double au lieu de les stocker en Currency comme il devrait… Mais pas sûr que ça changerait grand chose… Ça ne change déjà rien vu de VBA d'ailleurs. Une donnée Currency est stockée comme un nombre entier de 64 bits valant 10000 fois sa valeur conventionnelle. Il est donc toujours exact sur 4 décimales maxi.
Edit: CPU : Central Processing Unit. C'est l'élément principal de votre ordinateur, au centre de la carte mère. Toutes les applications sont obligées d'utiliser, par des instructions machine adéquates, les moyens mis à leur disposition par cet organe. Excel ne peut échaper à cette règle.
Non, il est dans l'impossibilité technique de les stocker avec exactitude en mémoire. Le mieux qu'on puisse faire pour 0,2 en binaire virgule flottante double précision c'est :
0,001100110011001100110011001100110011001100110011001101
qui vaut en fait 3602879701896397 × 2^-54
soit à peu près 0,20000000000000001110223024625157
Excel a toutefois peut être une lacune au sujet des valeurs de cellules munies d'un format monétaire on comptable. Il semblerait qu'il triche en les stockant aussi en Double au lieu de les stocker en Currency comme il devrait… Mais pas sûr que ça changerait grand chose… Ça ne change déjà rien vu de VBA d'ailleurs. Une donnée Currency est stockée comme un nombre entier de 64 bits valant 10000 fois sa valeur conventionnelle. Il est donc toujours exact sur 4 décimales maxi.
Edit: CPU : Central Processing Unit. C'est l'élément principal de votre ordinateur, au centre de la carte mère. Toutes les applications sont obligées d'utiliser, par des instructions machine adéquates, les moyens mis à leur disposition par cet organe. Excel ne peut échaper à cette règle.
Dernière édition:
Dranreb
XLDnaute Barbatruc
Bonsoir.
@rodge5895
Vous allez peut être m'objecter que lorsque vous voyez 0,2 dans une cellule c'est une représentation parfaitement exacte de la valeur que vous voulez, et elle est bien enregistrée quelque part en mémoire.
Le problème c'est qu'elle est impropre à l'utilisation en l'état dans des calculs parce que c'est du texte, forcément, sinon vous ne pourriez pas le voir.
C'est un texte reconstitué pour les besoins de l'affichage par combinaison de deux informations propres à la cellule: sa valeur et son format. Mais seule sa valeur intervient dans les calculs, or il peut être impossible qu'elle soit exactement égale à sa représentation en décimal si c'est un Double. Comprenez vous mieux ?
@rodge5895
Vous allez peut être m'objecter que lorsque vous voyez 0,2 dans une cellule c'est une représentation parfaitement exacte de la valeur que vous voulez, et elle est bien enregistrée quelque part en mémoire.
Le problème c'est qu'elle est impropre à l'utilisation en l'état dans des calculs parce que c'est du texte, forcément, sinon vous ne pourriez pas le voir.
C'est un texte reconstitué pour les besoins de l'affichage par combinaison de deux informations propres à la cellule: sa valeur et son format. Mais seule sa valeur intervient dans les calculs, or il peut être impossible qu'elle soit exactement égale à sa représentation en décimal si c'est un Double. Comprenez vous mieux ?
Discussions similaires
- Résolu(e)
- Résolu(e)
- Résolu(e)
- Question
