[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sas-l
Subject:    Re: Why the order of options matters in proc report ?
From:       Ya Huang <ya.huang () AMYLIN ! COM>
Date:       2012-06-28 14:35:28
Message-ID: 201206281435.q5S4PTqi020230 () waikiki ! cc ! uga ! edu
[Download RAW message or body]

uhuh! No wonder, I usually do not use them together, sometimes I happend
to use them together but with a 'right' order so it's OK.

Still if they are mutually exclusive, should't SAS send out some kind
of warning or note message?


On Thu, 28 Jun 2012 04:59:29 -0500, Data _null_; <iebupdte@GMAIL.COM>
wrote:

>On 6/28/12, Data _null_; <iebupdte@gmail.com> wrote:
>> The options are mutually exclusive the last one to appear is the one
>> you get.  Use the LIST option on the PROC statement to see how PROC
>> REPORT interprets the statements.
>>
>> 25   proc report data=sashelp.class (obs=6) nowd list;
>> 26   column sex name weight;
>> 27   *define sex /  display order;
>> 28   define sex /  order display;
>> 29   define name / display;
>> 30   define weight / display;
>> 31   run;
>>
>> PROC REPORT DATA=SASHELP.CLASS LS=123 PS=63  SPLIT="/" CENTER ;
>> COLUMN  ( Sex Name Weight );
>>
>> DEFINE  Sex / DISPLAY FORMAT= $1. WIDTH=1     SPACING=2   LEFT "Sex" ;
>> DEFINE  Name / DISPLAY FORMAT= $8. WIDTH=8     SPACING=2   LEFT "Name" ;
>> DEFINE  Weight / DISPLAY FORMAT= BEST9. WIDTH=9     SPACING=2   RIGHT
>> "Weight" ;
>> RUN;
>>
>> NOTE: There were 6 observations read from the data set SASHELP.CLASS.
>> NOTE: PROCEDURE REPORT used (Total process time):
>>       real time           2.23 seconds
>>       cpu time            0.12 seconds
>>
>>
>> 32   proc report data=sashelp.class (obs=6) nowd list;
>> 33   column sex name weight;
>> 34   define sex /  display order;
>> 35   *define sex /  order display;
>> 36   define name / display;
>> 37   define weight / display;
>> 38   run;
>>
>> PROC REPORT DATA=SASHELP.CLASS LS=123 PS=63  SPLIT="/" CENTER ;
>> COLUMN  ( Sex Name Weight );
>>
>> DEFINE  Sex / ORDER FORMAT= $1. WIDTH=1     SPACING=2   LEFT "Sex" ;
>> DEFINE  Name / DISPLAY FORMAT= $8. WIDTH=8     SPACING=2   LEFT "Name" ;
>> DEFINE  Weight / DISPLAY FORMAT= BEST9. WIDTH=9     SPACING=2   RIGHT
>> "Weight" ;
>> RUN;
>>
>> NOTE: There were 6 observations read from the data set SASHELP.CLASS.
>> NOTE: PROCEDURE REPORT used (Total process time):
>>       real time           0.04 seconds
>>       cpu time            0.04 seconds
>>
>>
>> On 6/28/12, Ya Huang <ya.huang@amylin.com> wrote:
>>> Hi there,
>>>
>>> I vaguely remember seeing this before. But it must be very long since
>>> last time I had this problem that I did not recognize it this time. I
>>> spent quite a while trying to figure out what went
>>> wrong. When I finally figured it out, I was quite pissed:
>>>
>>> proc report data=sashelp.class (obs=6) nowd;
>>> column sex name weight;
>>> *define sex /  display order;
>>> define sex /  order display;
>>> define name / display;
>>> define weight / display;
>>> run;
>>>
>>> this one by "order display" and unexpected result:
>>>
>>> sex  Name         Weight
>>>   M  Alfred        112.5
>>>   F  Alice            84
>>>   F  Barbara          98
>>>   F  Carol         102.5
>>>   M  Henry         102.5
>>>   M  James            83
>>>
>>> this one by "display order" and expected result:
>>>
>>> sex  Name         Weight
>>>   F  Alice            84
>>>      Barbara          98
>>>      Carol         102.5
>>>   M  Alfred        112.5
>>>      Henry         102.5
>>>      James            83
>>>
>>> In general, the order of options in a SAS statement does not seem to
>>> matter, these two are exceptions.
>>>
>>> Any reason why?
>>>
>>> Thanks
>>>
>>> Ya
>>>
>>
[prev in list] [next in list] [prev in thread] [next in thread]