Le Lundi 1 Octobre 2007 07:22, eric.bachard a écrit : > Bonjour Manuel, > > Manuel NAUDIN a écrit : > > voir ici : > > http://www.vnunet.fr/fr/vnunet/news/2007/09/28/excel-2007-choue-test-de-m > >ath > > En fait, c'est un bug d'affichage, car si on étend le calcul dans une > autre case, on trouve bien le bon résultat.
Certes mais sur un document comptable imprimé, que ce soit un bug d'affichage et non de calcul ne change pas grand-chose. > > On dirait un beau "cast manqué" entre le calcul et l'affichage. Je suis quand même perplexe. Comment ce genre de bug est-il possible ? Est-ce que M$ recode les opérations arithmétiques élémentaires ? Si j'avais ce genre d'erreur dans un code que j'ai écrit, ce serait une erreur du compilateur car je ne fais pas de calcul pour gérer les différents types d'affichage des valeurs numériques, tout ça est pris en charge par le langage de programmation et le compilateur. J'imagine que pour un tableur qui prend en charge tout plein de formats d'affichage différents, tout n'est pas prévu dans le langage de programmation et qu'il faut utiliser des algorithmes de conversion. Ce qui veut bien dire qu'il y a une erreur de calcul quelque part. Sans doute un effet de bord qui a été négligé ; en effet le résultat erroné n'est pas n'importe lequel puisque c'est 2**16 - 1 c'est à dire la plus grande valeur entière représentable sur 2 octets. JBF -- << Pour la pérennité de vos documents, utilisez des formats ouverts >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
