Cela fait un sacré bout de temps que je suis le site, d'habitude je suis complètement largué par les termes techniques de certains commentaires, mais pour une fois que je vois ce qui me semble être une erreur importante, je vais pas me géner ^^
D'ailleurs, je soupconne que le probleme vient plus du logiciel que du format.
En fait, c'est encore plus bête que ça, le problème vient de l'ordinateur. Ceci tient du fait que les nombre réels sont continus (je ne me rappelle plus le terme mathématique exacte :/) et que sur un ordinateur le stockage est forcément discret.
En pratique : 16 chiffres significatifs (pour un type double en C, mais bon moi et la programmation...) et une limitation de la plage? aussi.
Petite ex. amusant : (je l'ai fait dans octave mais on peut « s'amuser » à le coder aussi.) faire pi-3, on obtient 0.14... faire donc ensuite pi-3.1 on obtient 0.04, faire pi-3.14.. et ainsi de suite on rajoute un chiffre au soustracteur... on arrive finalement à obtenir pi avec 16 chiffres et une soustraction nulle !
Dans le même genre : faire (3e15-1)-3e15 puis (3e16-1)-3e16 ;)
Puis bon y'a aussi des divisions par des nombres très petits et autres joyeusetés du genre...
Donc pour pas être trop HS (on se ratrape comme on peut..:) ce n'est la faute ni à la norme ni au logiciel s'il « oublie » les derniers chiffres... par contre l'OOXML est complètement foireux puisque ce qu'il fait c'est interpréter un hypothétique 17 chiffres significatif comme étant un 9 (je soupçonne que dans word après avoir restocké les nombres en doubles on ne revienne à la véritable valeur ; mais c'est tout de même très bizarre comme façon de faire pour ne pas dire complètement idiote... on va dire qu'ils ont une bonne raison de la faire...)
[^] # Re: OOXML is defective by design
Posté par nicoastro . En réponse à la dépêche Pas de trève estivale pour la guerre des formats bureautiques. Évalué à 1.
Cela fait un sacré bout de temps que je suis le site, d'habitude je suis complètement largué par les termes techniques de certains commentaires, mais pour une fois que je vois ce qui me semble être une erreur importante, je vais pas me géner ^^
En fait, c'est encore plus bête que ça, le problème vient de l'ordinateur. Ceci tient du fait que les nombre réels sont continus (je ne me rappelle plus le terme mathématique exacte :/) et que sur un ordinateur le stockage est forcément discret.
En pratique : 16 chiffres significatifs (pour un type double en C, mais bon moi et la programmation...) et une limitation de la plage? aussi.
Petite ex. amusant : (je l'ai fait dans octave mais on peut « s'amuser » à le coder aussi.) faire pi-3, on obtient 0.14... faire donc ensuite pi-3.1 on obtient 0.04, faire pi-3.14.. et ainsi de suite on rajoute un chiffre au soustracteur... on arrive finalement à obtenir pi avec 16 chiffres et une soustraction nulle !
Dans le même genre : faire (3e15-1)-3e15 puis (3e16-1)-3e16 ;)
Puis bon y'a aussi des divisions par des nombres très petits et autres joyeusetés du genre...
Donc pour pas être trop HS (on se ratrape comme on peut..:) ce n'est la faute ni à la norme ni au logiciel s'il « oublie » les derniers chiffres... par contre l'OOXML est complètement foireux puisque ce qu'il fait c'est interpréter un hypothétique 17 chiffres significatif comme étant un 9 (je soupçonne que dans word après avoir restocké les nombres en doubles on ne revienne à la véritable valeur ; mais c'est tout de même très bizarre comme façon de faire pour ne pas dire complètement idiote... on va dire qu'ils ont une bonne raison de la faire...)