topic Re: if then and else then in SAS Procedures

if then and else then

deleted_user — Thu, 06 Jan 2011 16:50:40 GMT

What is the benefit of using else then with specified ranges?
data one;
set two;
if 8 gt age lt 10 then agecat=1;
else if 11 gt age lt 14 then agecat=2;
run;

Is there any benefit to adding "else" in the statement if you specify the range?

I'm just doing some searching and wondering if it's a preference of serves a purpose

Re: if then and else then

NickR — Thu, 06 Jan 2011 17:28:57 GMT

Using IF-THEN statements without the ELSE statement causes SAS to evaluate all IF-THEN statements.

Using IF-THEN statements with the ELSE statement causes SAS to execute IF-THEN statements until it encounters the first true statement. Subsequent IF-THEN statements are not evaluated.

You may refer SAS Online Documentation for more details.

Re: if then and else then

chang_y_chung_hotmail_com — Thu, 06 Jan 2011 17:36:43 GMT

Maybe no benefits at all. See some of more recently published SAS code, for instance,
KNOWLEDGE BASE / SAMPLES & SAS NOTES 33017 -- It does not bother to use ELSE IF at all. It goes, in part, like:

data new.newshoes;

set sashelp.shoes; /* the original data set */

if PRODUCT = "Boot" then NEWPRODUCT=1;

if PRODUCT = "Men's Casual" then NEWPRODUCT=2;

if PRODUCT = "Women's Casual" then NEWPRODUCT=3;

if PRODUCT = "Men's Dress" then NEWPRODUCT=4;

if PRODUCT = "Women's Dress" then NEWPRODUCT=5;

if PRODUCT = "Sandal" then NEWPRODUCT=6;

if PRODUCT = "Slipper" then NEWPRODUCT=7;

if PRODUCT = "Sport Shoe" then NEWPRODUCT=8;

format NEWPRODUCT productfmt.;

run;

Re: if then and else then

Reeza — Thu, 06 Jan 2011 18:03:08 GMT

What Nick R said.

Small enough difference, but this doesn't do much of a comparison, probably more pronounced in character or other types of comparison.
[pre]
data ifelse;
do i=1 to 1000000;
x=rand('normal', 0,1);
if x>0 then y=1;
else if x<=0 and x>-0.5 then y=0;
else if x<=-0.5 then y=2;
output;
end;
run;

data if;
do i=1 to 1000000;
x=rand('normal', 0,1);
if x>0 then y=1;
if x<=0 and x>-0.5 then y=0;
if x<=-0.5 then y=2;
output;
end;
run;
[/pre]

Message was edited by: Reeza Message was edited by: Reeza

Re: if then and else then

Peter_C — Thu, 06 Jan 2011 18:41:07 GMT

I think there is no benefit in excluding the ELSE in that example.
I prefer to avoid the IF as well as the ELSE for these situations.
I would create a "user defined format" with PROC FORMAT and use a put function to derive that ageCat, something like

ageCat = put( age, myFmt. );

creating that range-to-value format is simply:
proc format;
value myFmt
8 - 10 = 1
11-14 = 2
;
run;

of course the nuisance is that the put() returns a string only, but if the category really has to be a number, then
ageCat = input( put( age, myFmt. ), best8. ) ;

Probably it is always worth using the user-format approach when there is only one outcome variable for a series of if-tests.

peterC

Re: if then and else then

ChrisNZ — Mon, 10 Jan 2011 23:19:20 GMT

If there is only one outcome variable for a series of if-tests, I also find
[pre]
data new.newshoes;
set sashelp.shoes;
NEWPRODUCT=ifn(PRODUCT = "Boot" , 1
,ifn(PRODUCT = "Men's Casual" , 2
,ifn(PRODUCT = "Women's Casual", 3
,ifn(PRODUCT = "Men's Dress" , 4
,ifn(PRODUCT = "Women's Dress" , 5
,ifn(PRODUCT = "Sandal" , 6
,ifn(PRODUCT = "Slipper" , 7
,ifn(PRODUCT = "Sport Shoe" , 8
, . ))))))));
run;
[/pre]
more legible than if tests. Otherwise the select statement is also handy.

Re: if then and else then

Peter_C — Mon, 10 Jan 2011 23:29:23 GMT

Would the which() function help in that situation?

Re: if then and else then

ChrisNZ — Thu, 13 Jan 2011 21:29:14 GMT

Peter, in this case it would, but this is an example, values are random and don't matter here.

One thing: the embedded ifn() suite above would be a wee bit slower than a suite of if else statement as sas in their wisdom have chosen to always evaluate all arguments of the ifn/ifc functions, even though by design some will never be used. I hope that one day C=ifn(B=0,.,A/B); will not generate a division by zero error when B=0. It shouldn't.

Anyway, I am ready to trade the tiny performance hit for better code legibility.

Re: if then and else then

Peter_C — Fri, 14 Jan 2011 13:41:05 GMT

> Peter, in this case it would, but this is an example,
> values are random and don't matter here.
?????

> One thing: the embedded ifn() suite above would be a
> wee bit slower than a suite of if else statement
> Anyway, I am ready to trade the tiny performance hit
> for better code legibility.

Chris

I thought the informat technique would provide the clearest code while being simplest to manage.
Does it not also perform better than a series of logic tests on the same data (with/out ELSE)?

peterC

Re: if then and else then

sbb — Fri, 14 Jan 2011 14:18:33 GMT

I would say that a SAS FORMAT look-up (using a PUT function, or sometimes when using a PROC with a FORMAT statement) can be a more efficient performer depending on the search size. And I also would agree that the idea of maintaining a SAS format (no moving parts, like SAS statements) can also be more effective / efficient from a support perspective, particularly when using CNTLIN= to generate the FORMAT itself.

As well, consider that PROC FORMAT was enhanced with SAS version 6 to permit character-value range strings which afforded the opportunity for data-string prefix wildcarding, when coded correctly. Consider that SAS can be influenced in the search/match behavior, choosing either "most discrete match" or "first entry match" when using a particular user FORMAT, as well.

Scott Barry
SBBWorks, Inc.

Suggested Google advanced search argument, this topic / post:

proc format character value range site:sas.com

Re: if then and else then

ChrisNZ — Tue, 18 Jan 2011 02:18:22 GMT

I meant to say that several embedded ifn() calls can be more legible than if/then statements.

Informats can be clearer or not, and easier to maintain or not depending on the situation. They are defined outside of the datastep in any case, so require non-sequential reading to understand the logic.

All methods have their place, as usual: select, if/then, ifn(), proc format with values, proc format with cntlin datasets. I just wanted to mention embedded ifn()'s legibility as this function is more recent.

Formats using put() can be slower than tests, as functions are much slower than tests. In any case, unless the code is run billions of times it doesn't really matter. Legibility matters most imho.

Here are a few tests. [pre]
proc format;
value type low - 12 = '1'
13 - 19 = '2'
20 - high= '3';
run;
data _null_; * format 5.7s;
AGE=1;
do I=1 to 1e8;
TYPE=put(AGE, type.);
end;
run;
data _null_; * format+informat 6.9s;
AGE=1;
do I=1 to 1e8;
TYPE=input(put(AGE, type.),32.);
end;
run;
data _null_; * if 0.6s;
AGE=1;
do I=1 to 1e8;
if AGE le 12 then TYPE= 1;
if 13 le AGE le 19 then TYPE= 2;
if AGE ge 20 then TYPE= 3;
end;
run;
data _null_; * if else x1 0.5s;
AGE=1;
do I=1 to 1e8;
if AGE le 12 then TYPE= 1;
else if 13 le AGE le 19 then TYPE= 2;
else if AGE ge 20 then TYPE= 3;
end;
run;
data _null_;
AGE=31; * if else x3 0.7s;
do I=1 to 1e8;
if AGE le 12 then TYPE= 1;
else if 13 le AGE le 19 then TYPE= 2;
else if AGE ge 20 then TYPE= 3;
end;
run;
data _null_;
AGE=31; * ifn 7.8s;
do I=1 to 1e8;
TYPE=ifn( AGE le 12 , 1
,ifn( 13 le AGE le 19 , 2
,ifn( AGE ge 20 , 3, .)));
end;
run;
data _null_; * select 0.9s;
AGE=31;
do I=1 to 1e8;
select;
when( AGE le 12) TYPE= 1;
when(13 le AGE le 19) TYPE= 2;
when( AGE ge 20) TYPE= 3;
otherwise;
end;
end;
run;
data _null_; * test as number 1.8s;
AGE=1;
do I=1 to 1e8;
TYPE=( AGE le 12 ) * 1
+( 13 le AGE le 19 ) * 2
+( AGE ge 20 ) * 4;
end;
run;
[/pre]

Added "test as number" benchmark (Thanks André).

Re: if then and else then

ChrisNZ — Mon, 24 Jan 2011 02:36:02 GMT

>> Peter, in this case it would, but this is an example,
>> values are random and don't matter here.

>?????

I mean to say that instead of 1,2,3, etc, resulting values could be 1, 22, 56.

Chances are test-result values they will almost never be 1,2,3 in real life.
The discussion is about the best testing techniques. Which() only works if you want to retrieve the 1,2,3 suite of values, which have been chosen here by pure chance/laziness/lack of imagination. I have changed 3 to 4 in my last benchmark above. 🙂

>I thought the informat technique would provide the clearest code while being simplest to manage.

If one has a few cut-off values, I find having the values visible within the data step convenient most times. Of course there are times when one wants to keep all cut-off values together somewhere. Also, if there is a large number of cut-offs, the data step might be more legible without them. Clarity is in the eye of the beholder. 🙂

>Does it not also perform better than a series of logic tests on the same data (with/out ELSE)?

Not in the runs above. Functions are slower than tests. Using formats in procs is still very fast and convenient though.

Re: if then and else then

Peter_C — Mon, 24 Jan 2011 11:11:13 GMT

Chris
may I respond?

> >> Peter, in this case it would, but this is an example,
> >> values are random and don't matter here.
>
> >?????
>
> I mean to say that instead of 1,2,3, etc, resulting
> values could be 1, 22, 56.

That sounds like replacing input strings or values with a randomly distributed (but subset of the continuum of) values.
I have nothing to offer as a "best way" to derive one randon set of values from another, but I do have a use for (and thought we were discussing) determining an array index or table pointer from raw data.

> The discussion is about the best testing techniques.
> Which() only works if you want to retrieve the 1,2,3

>
> >I thought the informat technique would provide the clearest code while being simplest to manage.

> If one has a few cut-off values, I find having the
> values visible within the data step convenient most
> times. Of course there are times when one wants to
> keep all cut-off values together somewhere. Also, if
> there is a large number of cut-offs, the data step
> might be more legible without them. Clarity is in the
> eye of the beholder. 🙂

> >Does it not also perform better than a series of logic tests on the same data (with/out ELSE)?

> Not in the runs above.
> Functions are slower than tests.

This will be true when there are 4 tests for 1 function, and perhaps above 10:1.
I guess the threshhold is platform dependant.

I had in mind a credit risk staging area for a bank in which their solution for deriving "business product hierarchy" from a couple of data items was if/then/else SAS code built with a VBA macro from a decision tree table stored in excel.
For the user, changes meant re-aligning the decision tree, re-running the VBA macro and moving the generated code to the staging area application. The generated if/then/else logic ran to over 3000 lines (around 1500 tests). It was easy to avoid these tests appearing on the SASlog (/nosource2 on the %include).
Maintaining that VBA became unmanageable after personnel changed more than once. Re-writing the VBA in SAS did not take long, but still generated the vast collection of if/then/else code. The alternative solution, involving 2 informats with cntlin data sets from the decision trees, enormously reduced the if/then/else logic and ran a whole lot faster.

> Using formats in procs is still very fast and convenient though.

sure is!
and it is handy to have consistency when using the same format in both PROCs and data steps.

Re: if then and else then

ChrisNZ — Mon, 24 Jan 2011 22:05:12 GMT

Hi Peter,

>That sounds like replacing input strings or values with a randomly distributed ...

The values don't matter here, this is about methods of testing. Tested values or results could be strings in this case.

>This will be true when there are 4 tests for 1 function, and perhaps above 10:1.
I guess the threshhold is platform dependant.

Indeed. If a function is 10 times slower than a test, having more than 10 tests makes the function appealing again (and starts cluttering the data step too). As usual, one has to do one's home work depending on the particular circumstances. I suspect testing long strings would be more time consuming testing than short ones for example.

The main thing imho though, is that unless these tests are run millions of times, legibility matters most (whatever this means to each of us :o).

These runs give an overwhelming speed advantage to formats:

[pre]
%macro loop; * create a 2000-else-if test;
%do i=1 %to 2000;
else if A<&i then B=&i;
%end;
%mend;
data _null_; * 1 test before match 0.09s;
A=1;
do I=1 to 1e6;
if A<0 then B=1;
%loop
end;
run;
data _null_; * 1000 tests before match 7.2s;
A=1e3;
do I=1 to 1e6;
if A<0 then B=1;
%loop
end;
run;

%macro loop; * create a 2000-when test;
%do i=1 %to 2000;
when(&i) B=&i;
%end;
%mend;
data _null_; * select clause 17s;
A=1;
do I=1 to 1e6;
select(I);
%loop
otherwise;
end;
end;
run;
data _null_; * select clause 17s;
A=1e3;
do I=1 to 1e6;
select(I);
%loop
otherwise;
end;
end;
run;

proc format ; * create a 2000-entry format;
value test
%macro loop;
%do i=1 %to 2000;
&i="&i"
%end;
%mend;
%loop;
data _null_; * formats 0.09s;
A=1e3;
do I=1 to 1e6;
B=input(put(A,test.),32.);
end;
run;[/pre]

Re: if then and else then

Ksharp — Tue, 25 Jan 2011 02:40:56 GMT

Hi.Chris
Do you mean that proc format is the most efficient way for judge conditions?
What about some other people? Peter.C?

Ksharp

Re: if then and else then

Peter_C — Tue, 25 Jan 2011 10:43:47 GMT

no single approach suits all situations

Re: if then and else then

Ksharp — Wed, 26 Jan 2011 03:46:22 GMT

Haha.
Peter.C
Your words are too ambiguous , which can suit any situation.

Ksharp

Re: if then and else then

Peter_C — Wed, 26 Jan 2011 08:58:28 GMT

Ksharp

I think the original poster's question has been answered
"there is benefit from having ELSE among IF tests"

My answer is not "ambiguous" but neccessary a caution;
as I think there is no generally "best solution" because I think the "situation" (
data volumes,
IF complexity,
need for support/change-management by "others"
) are too important to ignore
but these allways vary

imho
peterC

Re: if then and else then

Ksharp — Thu, 27 Jan 2011 01:19:13 GMT

Peter.C
I agree with what you said.
But as my experience of processing data, proc format is actually to have less time.Namely I agree with Chris too.

:-)

Best Regards
Ksharp

Re: if then and else then

ChrisNZ — Thu, 27 Jan 2011 03:14:12 GMT

> no single approach suits all situations

I agree:

>As usual, one has to do one's home work depending on the particular circumstances
>The main thing imho though, is that unless these tests are run millions of times, legibility matters most

It would be as silly to never use formats as to never use tests in the situation discussed here.