récupérations de décimales [Résolu]

[AlexFred]

Bonjour,
Pouvez vous m'indiquer comment je peux afficher toutes les décimales dans la variable poids?
voir code

Code :

1
2
3
4
5
6
7
8
9
10
DATA pond;
INFILE datalines delimiter=','; 
   input num  ipondi $17.;
   datalines; 
1,0.945842216711826
2,3.582123456789012
;
DATA pond;SET pond; 
poids=input(ipondi,17.);run;
proc print DATA=pond;run;

voici ce que me donne le print.
Obs num ipondi poids

1 1 0.945842216711826 0.94584
2 2 3.582123456789012 3.58212

merci.

[debutsas]

essaye ça:

Code :

poids=input(ipondi, NUMX20.11);

[s_a_m]

20.11??? avec 15 décimales 16 avec le point (la virgule)!!

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
DATA pond;
INFILE datalines delimiter=','; 
   input num  ipondi $17.;
   datalines; 
1,0.945842216711826
2,3.582123456789012
;
DATA pond;SET pond; 
 
format poids 17.16;
poids=input(ipondi, 17.16); 
 
proc print DATA=pond;run;

[debutsas]

c'est pas faux ta réflexion sam.
merci

[AlexFred]

Merci S.A.M.
effectivement je récupère bien la pluspart des décimales.
Je perds juste un peu en précision pour la 2ème obs 010 au lieu de 012
Obs num ipondi poids

1 1 0.945842216711826 .9458422167118260
2 2 3.582123456789012 3.582123456789010

Comment je peux récupérer exactement le contenu ?

[datametric]

Avec

Code :

1
2
3
4
5
6
7
DATA pond;
SET pond;
ipondi2=ipondi*1; 
 
proc print DATA=pond;
format ipondi2 best30.;
run;

je pense que la limite est atteinte. Si tu veux plus alors je te conseille de le passer en char ou de créer un format avec PICTURE.

[olivier.decourt]

Bonjour.
La limite de précision de SAS est atteinte : il est dit ici qu'une variable numérique (longueur maxi = 8 octets, ce qui est la longueur par défaut et donc probablement la tienne) ne peut avoir plus de 15 chiffres significatifs. Ca correspond bien dans tes exemples au moment où les divergences apparaissent.
Conclusion : tu ne pourras pas utiliser davantage de précision sous SAS. Un format comme BEST32. pourrait te montrer plus de chiffres que les 15 significatifs mais ceux en surnombre seront "inventés" par SAS au moment du stockage de ta valeur.
Soit tu te contentes de cette précision (si je me souviens bien des autres topics où cette variable a été mentionnée, c'est une pondération : une dizaine de décimales devraient quand même suffire !) soit tu conserves ta variable sous forme de texte, mais avec l'impossibilité de calculer dessus...

Bon courage.
Olivier

[AlexFred]

Rappel
Olivier Decourt dit :

La limite de précision de SAS est atteinte : il est dit ici qu'une variable numérique (longueur maxi = 8 octets, ce qui est la longueur par défaut et donc probablement la tienne) ne peut avoir plus de 15 chiffres significatifs. Ca correspond bien dans tes exemples au moment où les divergences apparaissent.
Conclusion : tu ne pourras pas utiliser davantage de précision sous SAS. Un format comme BEST32. pourrait te montrer plus de chiffres que les 15 significatifs mais ceux en surnombre seront "inventés" par SAS au moment du stockage de ta valeur.
Soit tu te contentes de cette précision (si je me souviens bien des autres topics où cette variable a été mentionnée, c'est une pondération : une dizaine de décimales devraient quand même suffire !) soit tu conserves ta variable sous forme de texte, mais avec l'impossibilité de calculer dessus...

Il s'agit bien d'une pondération, mais je dois la récupérer avec les 15 décimales.
J'en suis pas loin et donc cela ne fausse pas trop les calculs.
Toutefois je suis curieux de comprendre pourquoi avec la solution de data métric je récupère 14 décimales, avec la solution de S_A_M j'en récupère 15, mais la 15ème est parfois pas la bonne.
De plus, dans la doc Sas je ne trouve aucun exemple de précision avec des décimaux.

Sous sas, il y a bien que 2 types de data Num ou Char, il n'y a pas de type Float, Real ...dble precision...?

En tous cas merci déjà pour vos réponses

[olivier.decourt]

Oui il n'y a que 2 types : numérique et caractère. Pas de DOUBLE, INT, FLOAT et autres BIG qu'on rencontre parfois dans d'autres logiciels.
La notion importante ici est celle de "chiffre significatifs" : ce n'est pas en nombre de décimales qu'on compte la précision dans SAS, mais en nombre de chiffres une fois éliminés les 0 les plus à gauche de la valeur. Ainsi tu auras davantage de décimales correctes avec un nombre du genre 0,123456789 qu'avec 3,123456789 car il faudra aussi stocker le 3 de la partie entière.

Quant à utiliser les 15 décimales dans les calculs, ce ne sera pas possible sous SAS Windows si des poids sont supérieurs à 1. Je lis bien dans la doc Insee des bases sur lesquelles tu travailles :

Les données étant issues d'enquêtes statistiques, l'ensemble des calculs doit être réalisé avec le poids de l'individu (IPONDI). Cette variable IPONDI est fournie avec des décimales pouvant aller jusqu'à 15 chiffres après la virgule. Afin d'éviter les erreurs d'arrondis, il est nécessaire d'utiliser le poids de l'individu en gardant les décimales dans les calculs.

Mais j'y comprends plutôt "n'essayez pas d'arrondir à l'entier les valeurs des poids, bande de #{#{@" ; les 15 décimales existent, elles ont été calculées, les calculs sont certainement plus exacts en leur présence, mais une douzaine de décimales doit suffire à une étude statistique normale. Parce que de toute façon ce sont des données d'enquête donc une fourchette d'erreur est à prévoir, dont l'amplitude dépassera très certainement l'impact d'une 13e ou 14e décimale pris en compte.
Et je tiens d'autant plus volontiers ce raisonnement que l'INSEE travaille quasiment exclusivement avec SAS. Il est donc peu probable qu'ils n'aient pas vu ces problèmes de précision surgir.
Enfin ce n'est que mon avis.

[AlexFred]

Merci Olivier,
pour ta réponse très précise et claire.
Cela explique tout à fait la perte de la 15ème décimale quand le chiffre est >1
Ma demande correspondait au recensement 2007.
Effectivement quand j'utilise le poids je retombe sur 63 574 062.7 au lieu de
63 574 063 habitants France entière

Mais on est perfectionniste ou pas !