Date:         Fri, 22 Oct 2010 19:14:09 -0500
Reply-To:     Joe Matise <snoopy369@GMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Joe Matise <snoopy369@GMAIL.COM>
Subject:      Re: Function vs. operator: if statement short circuit processing
Comments: To: Scott Bass <sas_l_739@yahoo.com.au>
In-Reply-To:  <201010230009.o9MJSW1t025206@malibu.cc.uga.edu>
Content-Type: text/plain; charset=ISO-8859-1

Don't know about performance, but they are NOT identical.

data _null_;
x = .A;
if (x ne .) then put "Not .";
if (not missing(x)) then put "Not Missing";
run;

Only one of those statements is true...

Would be interested as to why one but not the other short-circuits the if
statement, though. Perhaps it's the NOT operator that causes that issue?

-Joe

On Fri, Oct 22, 2010 at 7:09 PM, Scott Bass <sas_l_739@yahoo.com.au> wrote:

> Hi,
>
> Two questions:
>
> data _null_;
>   x=.;
>   if (x ne .) then do; * ... ; end;
>   if (not missing(x) then do; * ... ; end;
> run;
>
> 1)  Does anyone know if the SAS compiler is smart enough to generate the
> same compiled code for both lines?  Is the first line more performant than
> the second?  Does the second line generate a function call for each
> observation, or does the compiler transparently convert this to the
> equivalent of the first line?
>
> I've been using the 2nd approach a lot, thinking that it's slightly
> clearer,
> and I don't have to think about the data type of the variable.  However,
> neither of those are show stoppers; I can easily revert to the first
> approach if it performs better.
>
> 2)  And I can probably answer my own question #1 via the below code:
>
> data _null_;
>   x=.;
>   if ((x ne .) and (x + 5 > 7)) then put "YES";
>   if ((not missing(x)) and (x + 5 > 7)) then put "YES";
> run;
>
> Clearly they must not generate the same code, since the first line
> implements "short circuit" if processing, ending statement execution as
> soon
> as the first portion renders the entire statement false.
>
> Anyone know why the second statement results in "Missing values were
> generated as a result of performing an operation on missing values."?
>
> So if the answer to #1 is "first line performs better", then my use of the
> missing function is going to dramatically decrease.  Perhaps useful in a
> macro where the incoming variable data type is unknown, but otherwise...
>
> Thanks for any insights you can share.
>
> Regards,
> Scott
>