Statalist


[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

RE: st: problem creating and doing a foreach on a local of all numeric variables in a dataset


From   "Nick Cox" <n.j.cox@durham.ac.uk>
To   <statalist@hsphsun2.harvard.edu>
Subject   RE: st: problem creating and doing a foreach on a local of all numeric variables in a dataset
Date   Wed, 27 Aug 2008 17:07:55 +0100

Maarten has answered most of this. In effect you must save the contents
of r(varlist) before it is overwritten by the next invocation of -ds-. 

The evidence from using -display- needs to be thought about carefully.
My way of considering this is to stress that it is the job of -display-
to do its level best at evaluating whatever is put in front of it. Thus
with -display- the results after 

sysuse auto
su mpg, meanonly 

of 

di `r(min)' (1) 

and 

di r(min)   (2) 

are identical. But what is happening differs in the two cases. 

Let's twist terminology and truth by focusing on the part of Stata that
looks at your command line to see if it makes sense, calling this the
"parser". 

In (1) you insist to the parser that it evaluate r(min) as it were a
local macro. Thus what is passed to -display- is 

di 12 

and surprise, "12" is displayed. The `r(min)' was interpreted before
-display- ever started work. 

In (2) however you pass r(min) to -display- and make -display- do some
work and look inside r(min), which here is a saved result without macro
flavour. This works too, which is good fortune, or rather the way that
-display- was designed to work. 

At least that is how I think of it. Otherwise put, I think of -display-
as an indulgent command that will do some work if it has to. 

However with say -foreach- what you are seeing is different. What you
reported earlier shows one main thing: that the parser can't make sense
of 

foreach var of local `num_vars' {

which evaluates to 

foreach var of local r(varlist) { 

which is itself not legal syntax, as r(varlist) cannot be the name of a
local macro. The error message doesn't say that, and you get booted out
for other reasons, but that is the real reason! 

It would be legal to write 

foreach var in r(varlist) {

but it wouldn't help you because the r(varlist) would not get expanded
so that you passed its contents to -foreach-. Hence you need the ` ' to
insist on pre-processing. 

Thus -foreach- is a strict command. It will do rather little
pre-processing for you. What is does is strictly implied by the help
statement, or the other rules of Stata. There is no homunculus inside
-foreach- as there is inside -display- willing to try to work out what
you mean. 

In short, 

. display <macname> 

can be misleading on what will happen given <macname> elsewhere. My
usual habit in debugging is to get -macro list- to tell me what Stata
thinks is what. 

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

Jennifer S. Earl

Thanks Maarten and Nick-- it runs now! I would have never figured out
that 
was the problem, especially since the "display `num_vars'" did display
the 
full list of variables I wanted even while I got the errors in the
foreach 
loop.

Just so I understand, though, I'll ask a follow-up:
Let's say I wanted to name the initial list of numeric variables
something 
different than the initial list of string variables (hence me trying to
put 
them in the local macros num_list and string_list) so I could use these 
lists at different points later in the program and the lists would not
be 
affected by subsequently created variables (as they would if I just
remade 
the lists each time).

Right now, I could not do this because both the numeric and string lists

both appear to be called `r(varlist)' ; the contents just got replaced
by 
running "ds , has(type numeric)" or "ds , has(type string)" right before

the foreach loop.

How could I save off those initial lists and then later successfully 
operate on them in a foreach loop?


*
*   For searches and help try:
*   http://www.stata.com/help.cgi?search
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index