Cast vers un type plus grand et perte de precision

Bonjour.

Une question me taraude depuis un certain temps :

Considérons deux façons d'effectuer un calcul :

Possibilité 1 :
1) données en double precision
2) application d'une fonction sur ces données ou tous les types temporaires sont des doubles
3) retour du resultat en double precision

Possibilité 2 :
1) données en double précision
2) cast des données vers des long double
3) application d'une fonction sur ces données ou tous les types temporaires sont des long double
4) cast du résultat de long double vers un double
5) retour du résultat en double precision

A la fin j'aurai le même nombre de chiffres après la virgule. Cependant, il peut y a avoir des différences dans le résultat. La question que je me pose est la suivante :

Est-ce que la 2ème façon de procéder peut donner un résultat plus éloigné du résultat analytique que la 1ère et si oui dans quel cas par exemple ?

Merci beaucoup.

PS : sur la plateforme que j'utilise : sizeof(float) = 4, sizeof(double) = 8, sizeof(long double) = 16

question complexe, quelques elements de reponse ici:

http://randomascii.wordpress.com/201...int-precision/

Citation:

Envoyé par Kaluza

A la fin j'aurai le même nombre de chiffres après la virgule. Cependant, il peut y a avoir des différences dans le résultat. La question que je me pose est la suivante :

Est-ce que la 2ème façon de procéder peut donner un résultat plus éloigné du résultat analytique que la 1ère et si oui dans quel cas par exemple ?

Dans l'absolu, oui. On peut très bien imaginer, dans le même esprit, de 1) partir d'un int, le convertir en double, faire les calculs et re-convertir le résultat en entier ou 2) faire tous les calculs directement sur des entiers. On imagine bien que dans le second cas, chaque fois que le résultat d'une opération ne sera pas entier, on perdra de l'information.

Sinon, les principaux cas concernés sont ceux où les erreurs se cumulent. Par exemple, avec une progression géométrique de raison irrationnelle, ou lors d'exponentiations successives.

Voici un exemple ou je pars de 1,2, soit légèrement en dessous de 10^(1/10). C'est une valeur intéressante parce qu'elle est finie en décimale mais pas en binaire. Il y a donc un arrondi qui est appliqué, donc une imprécision qui peut se propager.

J'affecte cette valeur à un double « x » et je copie celui-ci dans un long double « y ». Ils sont donc censés contenir la même configuration de bits, comblée par des zéros dans le second cas. Je les multiplie ensuite dix fois par eux-mêmes. J'affiche les deux résultats, puis je convertis y en double et j'affiche également le résultat de la conversion.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 #include <stdio.h> int main (void) { int i; double x; long double y; x = 1.2; y = x; printf ("x start : %f\n",x); for (i=0;i<10;++i) x *= x; printf ("x end : %f\n",x); printf ("y start : %Lf\n",y); for (i=0;i<10;++i) y *= y; printf ("y end : %Lf\n",y); printf ("y double : %f\n",(double)y); return 0; }
Code:

1 2 3 4 5 6 $ ./calcul x start : 1.200000 x end : 1206690664274127185924980567972900085846591379277237189994378260649628705381941248.000000 y start : 1.200000 y end : 1206690664274112834451295821409252676013494557525139169940684154178653027569762304.000000 y double : 1206690664274112863453313644195509168994826400098441820261403785970498119088996352.000000
Malgré un type initial plus précis, le long double converti en double affiche un résultat différent du double seul. Et pourtant, dix itérations de x², c'est loin d'être exceptionnel, surtout en astrophysique.

C'est important parce qu'un simple float est déjà censé être suffisant en soi pour la plupart des cas courants et utiliser double à tout bout de champ n'a réellement cessé d'être pénalisant qu'avec l'arrivée des machines 64 bits. La plupart des gens le faisaient quand même systématiquement par défaut, d'une part parce que c'est le type par défaut utilisé par le C lorsqu'on utilise des constantes décimales, ensuite parce que la plage couverte par un double a l'air tellement immense vue comme ça qu'on était persuadé que s'il y avait de légers risques avec des float, ils auraient complètement disparu avec les double.

Travailler avec des long double est vorace en ressources, donc autant être sûr de ce qu'on fait à l'avance ! :-)

Salut,
Au delà de la représentation, ça ne demande pas d'avoir auparavant fait une analyse de stabilité numérique des fonctions appelées ? De mémoire, des petites erreurs peuvent parfois avoir des effets désastreux sur la convergence des résultats et il vaut mieux parfois partir d'éléments moins précis.