Arrondi nombres décimaux [Résolu]

[jdesert]

Bonjour à tous,

je sollicite votre aide pour un truc qui me laisse vraiment perplexe.

Sous SAS j'effectue l'opération suivante :

66001042444 * 2.07 qui me donne bien le résultat attendu : 136622157859,08.

Pour vérifier la précision de la variable résultante j'ai fait ceci :

Code :

1
2
3
4
DATA lol;
	 int_tronc1 =66001042444 * 2.07;
	int_tronc2 = int_tronc1 - int(int_tronc1);
run;

la variable int_tronc2 est donc la différence entre le résultat et la partie entière, le résultat attendu est 0.8. Or, j'obtiens plutôt 0.0799865723.

C'est très génant puisque je développe un module de vérification de précision et que SAS introduit des imprécisions ici.

Quelqu'un saurait comment résoudre le phénomène (et l'expliquer si possible )?

[Manoutz]

Il est probable que ce soit lié au format que tu utilises. Vérifie le format de ta variable. Par exemple, le format best12: numérique avec 12 chiffres/point maximum, sas choisi la meilleure notation de sorte à tronquer le moins possible. Les décimales pourront être tronquées s’il n’y a pas assez de place, voir les entiers.

A toi de choisir le format qui correspond le mieux, tu peux par exemple passer en best16. voire plus, ou choisir un autre format

http://support.sas.com/onlinedoc/913...a001263753.htm

[jdesert]

Merci pour ta réponse Manoutz.

Je dois dire que malgré le changement de format, le problème demeure :

Code :

1
2
3
4
5
DATA lol;
	format int_tronc1 int_tronc2 best18.;
	 int_tronc1 =66001042444 * 2.07;
	int_tronc2 = int_tronc1 - int(int_tronc1);
run;

La variable int_tronc2 vaut 0.07998657226562 au lieu des 0.8.

[Manoutz]

et si tu mets un best20. sur int_tronc1 ca donne quoi?

[Manoutz]

tu peux aussi forcer le nombre de décimales en utilisant un format de type w.d
(exemple 20.2)

[jdesert]

Tu es grand Manoutz, !

Tu viens de m'apprendre un truc énorme, j'avais jamais tilté que le format BEST laissait SAS choisir le format le plus pertinent.

Merci

[xav2229]

c'est parce que tu crois que le résultat de int_tronc1 est 136622157859.08

mais ce n'est pas le cas!

pourquoi ?

Une des raisons est que SAS code les chiffres sur 8 bits, donc pour des chiffres a virgule il peut y avoir une perte de précision quand les chiffres sont gros.

Fait le même calcul sous Excel tu verras le même résultat.

xav

[jdesert]

Je ne suis pas sûr de te suivre xav2229.

J'ai recalculé int_tronc1 sur Excel 2007 et j'ai bien trouvé le résultat 136622157859.08

Ensuite, le problème pour moi n'est pas la perte de précision mais une gestion bizarre des décimales, puisque si Excel a raison (et ma calculatrice), pourquoi SAS transforme le .08 en .07998... ?

Par contre, si j'ai saisi l'idée, tu me dis que c'est impossible de régler ca du fait de la gestion mémoire des nombres sous SAS. C'est bien ça ?

[Manoutz]

Xav ou moi, le message est le même!

Vérifie la valeur exacte de 66001042444. La valeur affichée doit être arrondie, car si tu multiplie par 2.07, ca peut pas donner qqc à 10 décimales. Sous excel tu peux aussi appliquer des formats

[xav2229]

A tester sous Excel :

A1 = 66001042444
B1 = 2,0700
C1 = B1*A1
C2 = 136622157859

Que vaut D2 quand D2=C1-C2 ?

et choisit 30 chiffres après la virgule

[jdesert]

J'espère que vos messages ne sont pas les même.

Je n'ai pas besoin de vérifier la valeur de 66001042444 puisque je la rentre en dur.

Si tu exécutes le code ci-dessous, tu devrais constater l'erreur, les formats ne faisant que masquer le problème.

Code :

1
2
3
4
DATA lol;
int_tronc1 =66001042444 * 2.07;
int_tronc2 = int_tronc1 - int(int_tronc1);
run;

Entre parenthèses, je m'étais un peu enthousiasmé pour rien, le problème n'était pas résolu comme tu l'auras compris.

[jdesert]

Mea culpa, je me suis pris à douter de SAS plutôt que des autres sources.

Merci à vous deux.

[Manoutz]

tu peux palier au problème en utilisant la fonction mod

Code :

1
2
3
4
DATA lol;
int_tronc1 =66001042444 * 2.07;
int_tronc2 = mod(int_tronc1,1);
run;