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
Content-Type: text/plain; charset=ISO-8859-1
Don't know about performance, but they are NOT identical.
x = .A;
if (x ne .) then put "Not .";
if (not missing(x)) then put "Not Missing";
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?
On Fri, Oct 22, 2010 at 7:09 PM, Scott Bass <firstname.lastname@example.org> wrote:
> Two questions:
> data _null_;
> if (x ne .) then do; * ... ; end;
> if (not missing(x) then do; * ... ; end;
> 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
> 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_;
> if ((x ne .) and (x + 5 > 7)) then put "YES";
> if ((not missing(x)) and (x + 5 > 7)) then put "YES";
> Clearly they must not generate the same code, since the first line
> implements "short circuit" if processing, ending statement execution as
> 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.