Discussion :

[Phil991]

Bonjour,

J'utilise GMP pour développer un programme qui effectue différents calculs astronomiques. Quand j'utilise des entiers, pas de problème mais quand j'utilise des floats, il y a comme un problème de précision ou d'arrondis.

Le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#include <gmp.h>
 
void main() {
 
mpf_t G; // Déclaration
mpf_init (G); // Initialisation
mpf_set_d (G, 0.000000000667428 ); // Affectation
gmp_printf("G = %Ff\n", G); //Affichage
}

Sortie :
0.000000000667428000000000024141

Ce sont les derniers chiffres qui me posent problème.

Pour
mpf_set_d (G, 1.989e30 );

J'obtiens :
1988999999999999901910000000000

Pourquoi ces résultats?
J'utilise gcc 4.4.5 sur Linux Ubuntu 10.10.
Merci d'avance pour les conseils que vous pourrez me donner !

[Obsidian]

C'est probablement dû au fait que, lorsque tu appelles ta fonction d'affectation, tu passes ta valeur en argument, et celui-ci lui est transmis par le C. Ton argument est donc un double ordinaire avant d'être traité par GMP, et est donc soumis aux mêmes imprécisions.

Par ailleurs, un nombre fini dans une base peut ne pas l'être dans une autre, typiquement en binaire. C'est le cas de « 1,2 », par exemple, qui n'a pourtant par l'air méchant à première vue. Et là, malheureusement, quelque soit la précision adoptée, cela restera toujours une valeur approchée.

Pour la dernière valeur, toutefois, il s'agit d'un nombre entier (parce que « e30 »). Essaie d'écrire 1989e27, pour voir…

[Phil991]

C'est drôle (si on veut) car en faisant ça, ça m'affiche d'autres chiffres à la fin. Mais le problème persiste... Mais je pense que ça vient de GMP car GMPFR (qui vient de GMP) donne la même chose. D'ailleurs, on peut voir ça directement sur http://ex-cs.sist.ac.jp/~tkouya/try_mpfr.html qui utilise GMPFR car quand on tape 1989e27 avec une précision de 64 bits on obtient 1.98900000000000000004e30. En revanche, pas de problème lorsque l'on choisit une précision de 128 bits. Bug aléatoire...

[Obsidian]

Ce n'est pas un bug aléatoire, c'est probablement un arrondi par excès ou par défaut en fonction de la position dans la séquence.

Il est facile de montrer que 1.989 n'est pas un nombre fini en binaire : de la même façon que l'on divise par successivement par deux un nombre entier pour le traduire en binaire, en regardant si le résultat est entier ou non, autrement dit : si un bit a « passé la virgule », il suffit de multiplier successivement sa partie décimale par deux pour la traduire à son tour, en regardant si le résultat est de la forme « 0,xxx » ou « 1,xxx », donc si un bit a passé la virgule, mais dans l'autre sens.

Or, si je multiplie un nombre à trois décimales par un nombre entier (« 2 »), les chiffres significatifs ne peuvent progresser que vers la gauche, en espérant qu'ils disparaissent totalement. En tout état de cause, il n'y aura jamais plus de trois décimales aux résultats intermédiaires.

Or, la troisième décimale (la plus faible) est un 9. Multipliée par deux, elle devient 8 (car 9×2=18, je pose 8 et je retiens 1), puis 6 au tour suivant (car 8×2=16), puis 2 (car 6×2=12), puis 4, puis … 8 ! On se retrouve dans le deuxième cas. Par conséquent, la troisième décimale va « cycler » sur ces quatre dernières valeurs. Elle ne sera donc jamais résorbée, donc les autres décimales ne le seront jamais non plus, donc le nombre n'atteindra jamais 0,000 au bout d'une multiplication et, donc, 1,989 ne peut pas être écrit de manière finie en binaire.

Ça veut dire que même avec une précision de 16384 bits, ton nombre sera toujours une valeur approchée en binaire. Mais si le dernier bit est un 1 et pas un 0, elle sera arrondie par excès. Il faut alors soit ajouter des bits, soit redescendre en précision, si tu as beaucoup de zéros intermédiaires, pour que la « coupure » se situe avant le chiffre imprécis.