Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.

# st: RE: Evaluating a set of conditions

 From "Nick Cox" To Subject st: RE: Evaluating a set of conditions Date Wed, 16 Jun 2010 23:55:53 +0100

```It is difficult to add much here at a general level.

I guess what will be obvious, but also remains important even as you
grow in Stata skills, is that clarity of code is never to be
undervalued, that is, even clever ways of coding more concisely are a
distraction if whoever reads the code -- most likely you, sometime in
the future -- has to struggle to understand it.

-cond()- grows on you. I had the interesting but probably unusual
experience that a concatenation of circumstances led to my writing an
article on it with David Kantor. That forced me to think very hard about
the logic of -cond()- and led to my using it much more than previously.
I am not sure that making yourself write an article will be a practical
way for many users to become familiar with something, but nevertheless,

the underlying message, although trite, is also fundamental: what you
understand well you tend to use a lot; but also if you get to use
something a lot, you will get to understand it better.

I wouldn't try to rewrite your example. It shows an extra detail: never
be reluctant to parenthesise aggressively using () to emphasise meaning.
I probably wouldn't get high marks on a quiz on Stata's precedence rules
despite 20 years of Stata use, as if in doubt I just parenthesise to
emphasise my logic to myself as well as Stata.

Nick
n.j.cox@durham.ac.uk

Thomas Speidel

I realize this is a very broad question and no one solution can fit
all problems. I am looking for more efficient or elegant alternatives
to evaluate a set of conditions in Stata, than a lenghty if qualifier.
E.g.:

do something if A==1 & (B>2 & B<.) & (C==1 | D!=2)

these expression can become lengthy and one can think of more elegant
ways to come to the same results.
cond and inrange are the first things that come to my mind that may
(or may not) simplify the problem, but I hardly ever use them because
understanding them (or remembering them) usually takes longer then
writing the 'lengthy' qualifiers.
To complicate matters one has to account for missing values.