any way to nest or organize if statements in STATA?

[Chung Kim]

I'm rewriting a SAS code into STATA and had learned quickly the big difference between each software's if command (captured here in Cox's answer to my earlier question http://www.statalist.org/forums/foru...and-delimiters), that STATA nested ifs don't loop over.

But I'm wondering if there is any way to create "neater" looking conditionals in STATA. For example, something in SAS that looks like this,

if condition A {

if condition a {

[INDENT=2]do 1[/INDENT]

}

if condition b {

[INDENT=2]do 2[/INDENT]

}

}
if condition B {

if condition c {

[INDENT=2]do 3[/INDENT]

}
if condition d {

[INDENT=2]do 4[/INDENT]

}

}

will have to be written like this in STATA

do 1 if condition A & condition a
do 2 if condition A & condition b
do 3 if condition B & condition c
do 4 if condition B & condition d

which, with long conditionals and action commands, looks messy and is hard to keep track of. Any advice on this issue would be appreciated.

[Rich Goldstein]

with the "if" command, if that is really what you want, you can certainly use "else"; see "help ifcmd"; I don't know SAS so don't know if this is what you want

[Chung Kim]

I know that when the if command, as opposed to the if qualifier, is applied to evaluate a variable, it only evaluates the first observation and takes the boolean. That is not what I want.

[Chung Kim]

To clarify, I'm wondering if there are ways to organize if qualifiers, especially when there are overlapping if qualifiers for multiple commands in succession.

[Nick Cox]

I don't think you have given us any details that allow extension of the previous answer by Rich Goldstein.

It's also unclear why you regard the structure you sketch as "messy". For all that it may be unfamiliar to you it's not more complicated than what you had in mind originally.

[Chung Kim]

I consider the sketch is messy because it's hard to keep track of which commands share the same if qualifiers when that knowledge may be some benefit to me. This code I'm dealing with has long and multiple if qualifiers that I need to type in again and again so I'd much prefer some sort of nested form. It appears as though there is no other way to get around this issue.

[daniel klein]

Perhaps someone could suggest an alternative way of approaching the underlying problem, if you tell us a little bit more about it.

I do not have the faintest idea about SAS, but what is implied in Stata by

do 1 if condition A

is that 1 is some Stata command (that usually operates on variables (vectors)) and A is itself a variable (a vector) for which condition is to be evaluated for every observation. This is probably not what you want.

Best
Daniel

[William Lisowski]

I have to agree with the Chung Kim that, accustomed as I am to programming in languages with the sort of structure offered by SAS's general if/then/else, as well as by Stata's if/then/else "programming" commands, including grouping with braces, the limitation of Stata's data manipulation commands to a simple "then/if" format makes my code more cumbersome and error-prone. I used to work with someone who always advised increasing reliability by "keeping the programmer out of the middle of the loop", and repeating the same, or similar, if clauses from command to command is the antithesis of that advice.

However, I agree with the conclusion in post #6. As much as I might wish it otherwise, Stata's historical syntax is what it is.

[Nick Cox]

You can insert braces and/or comments ad libitum if you wish:

 
{   // condition A 



}

Experienced Stata programmers often insert comments and sometimes insert braces even if there no syntactic need. A matching pair of braces that is consistent with other syntax is perfectly legal.

[Svend Juul]

Is it something like this you mean? It is perfectly doable in Stata. I don't know about SAS

if condition A {
    if condition a {
        do 1
    }
    else if condition b {
        do 2
    }
}
else if condition B {
    if condition c {
        do 3
    }          // end condition c
    else if condition d {
        do 4
    }          // end condition d
}              // end condition B

[William Lisowski]

In Chung Kim's original post, the conditions and actions to relate to the data, not to programming constructs like macros. Thus the Stata commands

generate x2 = 5 if z2==7
generate x3 = 42 if z2==7 & z3==5

could be written in SAS as

if z2=7 then do;
    x2 = 5;
    if z3 = 5 then do;
        x3 = 42;
    end;
end;

Some of us find this a more congenial style of programming -- clearly delimiting which commands must satisfy similar conditions -- especially for code significantly more complex than my simple example.

But this depends on SAS's notion of a "data step" gathering a group of non-analysis commands into a single procedure, as opposed to Stata's notion of executing each command as it comes along. Stata's model has its own strengths, in particular, the use of macros is much more straightforward than the equivalent concept in SAS.

De gustibus non est disputandum.

[Mike Lacy]

My sense is that Chung Kim's issue is with if-qualifiers in -generate- or -replace-, and that his reference to -do if- is to be regarded as pseudo-code, not Stata's -do- command. My initial view of Stata's lack of block-if functionality on qualifiers was also to be dissatisfied, and in fact I think I posted a complaint on the old StataList to this effect. However, my concern was in relation to the inefficiency of repeated evaluation of ... if A..., if A. My experience over time is that I don't notice the inefficiency, and that this construction is less common than I thought, perhaps less common in Stata than other languages. As for readability, a sentiment with which I sympathize, I have sometimes found that putting the constant part of the -if- on one line and the changing part on the next can be helpful, such as:

gen x = y if some long set of conditions prevails  ///
                  & (C | D)
replace x = z if some long set of conditions prevails ///
                  & (!D & E)

I'd also say that if the conditions are long and complicated, making an auxilliary boolean variable, rather than repeating complicated constructions, is much nicer to the eye and mind of some human beings.

Regards, Mike