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

From |
Fred Wolfe <fwolfe@arthritis-research.org> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
Re: st: Re: Interesting (and frustrating) log problem |

Date |
Mon, 28 Jun 2004 10:04:26 -0500 |

Thanks. At 09:47 AM 6/28/2004, you wrote:

I think what you are seeing is intended behavior and I would guess that your foreach loop has 242 lines. Stata's output for loops shows each line of the loop once (numbered) and then shows all of the output without showing you the commands for that iteration of the loop. I usually include lines in the loop to display relevant information about what each result refers to or else I re-write the inside of the loop as an ado file that produces labeled output I want and then just call the ado file inside the loop.

Thanks, that's what I ended up doing.

For your example, program define myprog syntax using/ use `using', replace .... noi di "Regression of ......using `using'" ... end foreach name in solpro1 solpro2 solpro3 solpro4 solpro5 { myprog using `name' } Michael Blasnik michael.blasnik@verizon.net ----- Original Message ----- From: "Fred Wolfe" <fwolfe@arthritis-research.org> To: <statalist@hsphsun2.harvard.edu> Sent: Monday, June 28, 2004 8:09 AM Subject: st: Interesting (and frustrating) log problem > I have encountered an unexpected problem within a Stata log. > > I build a foreach loop, thusly: > > local counter 0 > foreach name in solpro1 solpro2 solpro3 solpro4 solpro5 { > local counter = `counter' + 1 > use `name', clear > // fix sas transfer file - solas naming problem > rename totinco totincom > rename pain_sc pain_sca > rename haq_dis haq_disa > cap drop _merge > dmerge spatkey using crproduct3, unique > keep if _merge == 3 > > Many commands including saving 6 files follow > > loop closes > > The log put in the following output: > > . foreach name in solpro1 solpro2 solpro3 solpro4 solpro5 { > 2. local counter = `counter' + 1 > 3. use `name', clear > 4. // fix sas transfer file - solas naming problem > . rename totinco totincom > 5. rename pain_sc pain_sca > 6. rename haq_dis haq_disa > 7. cap drop _merge > 8. dmerge spatkey using crproduct3, unique > 9. keep if _merge == 3 > 10. > . > . // section on predicting income among workers > . > . gen college = edcat==4 > 11. label variable college "College education" > 12. > > <snip> > > 238. if `counter' == 1 { > 239. save masterproduct3, replace > 240. } > 241. save m`name', replace > 242. } > (253 observations deleted) > (780 real changes made) > (81 real changes made) > (11 real changes made) > (6396 missing values generated) > (6396 missing values generated) > (6396 missing values generated) > (6396 missing values generated) > > Fitting constant-only model: > > <much more follows> > > Notice that it counts to 242, displays each command and output. > > At that point the numbers stop, the program continues but displays no > command, such that I can't figure out what command called the regression > analyses. And I think the results that I am getting may be wrong. The Ns > appear to be inappropriate. > > I looked in -help limits- '244' is the max length of a string expression. > Is this the problem? In any event, if it is Stata should stop or give an error. > > This is very strange behavior. > > Any thoughts? > > Thanks, > > Fred * * For searches and help try: * http://www.stata.com/support/faqs/res/findit.html * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

Fred Wolfe National Data Bank for Rheumatic Diseases Wichita, Kansas Tel (316) 263-2125 Fax (316) 263-0761 fwolfe@arthritis-research.org * * For searches and help try: * http://www.stata.com/support/faqs/res/findit.html * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**References**:**Re: st: How to get covariate names after OLS regression***From:*Joseph Coveney <jcoveney@bigplanet.com>

**st: Interesting (and frustrating) log problem***From:*Fred Wolfe <fwolfe@arthritis-research.org>

**st: Re: Interesting (and frustrating) log problem***From:*"Michael Blasnik" <michael.blasnik@verizon.net>

- Prev by Date:
**st: Re: Interesting (and frustrating) log problem** - Next by Date:
**Re: st: Re: Interesting (and frustrating) log problem** - Previous by thread:
**st: Re: Interesting (and frustrating) log problem** - Next by thread:
**Re: st: Re: Interesting (and frustrating) log problem** - Index(es):

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