Is there a more efficient way to run three statsby regressions with different reference groups?

Question

I want to run these three regressions. Note that each has a different reference group, which is why I run them separately.

1. statsby _b, by(grp_iden) saving(reg_aaa.dta, replace): reg prezzo ib43.city_str i.marca_str, baselevels

2. statsby _b, by(grp_iden) saving(reg_bbb.dta, replace): reg prezzo ib6.city_str i.marca_str, baselevels

3. statsby _b, by(grp_iden) saving(reg_ccc.dta, replace): reg prezzo ib11.city_str i.marca_str, baselevels

However, before running each, I resort to the following:

Before running regression (1), I use: keep if rcode=="aaa"

Before running regression (2), I use: keep if rcode=="bbb"

Before running regression (3), I use: keep if rcode=="ccc"

Is there a way to run the three statsby regressions more efficiently, and perhaps without the need to drop observations from the sample before each respective regression?

Something like the following could work, but I would need to find a way to select different reference groups (i.e., different XX in ibXX.city_str) in each rcode set:

statsby _b, by(rcode grp_iden) saving(reg_ccc.dta, replace): reg prezzo ib11.city_str i.marca_str, baselevels

Answer 1

You might use a loop over 43 6 11 and also over aaa bbb ccc:

tokenize "aaa bbb ccc" 
local x = 1 
foreach g in 43 6 11 { 
    statsby _b, by(grp_iden) saving(reg_``x''.dta, replace): reg prezzo ib`g'.city_str i.marca_str if rcode == "``x''", baselevels
    local ++x 
}

I have very mixed feelings about such coding. Sure, you exploit common structure to make the code shorter. If the real problem included say 10 cases, that would clean up the code a lot. If the real problem were very similar, you might lose much clarity, for yourself later, for people in your team, and for other people trying to understand your code. A sharp test is that if you didn't see how to do this yourself, it may be trickier than you should want to use. But it's also true that we only grow by seeing how to use language features, which then become part of our basic toolkit.

Efficiency always sounds better than its lack, but making code more clever but less clear is often not a good idea. The time gain from a loop is dubious: Stata in fact has to interpret the looping machinery, although the cost of that should be trivial. Always include time spent reading the code in your consideration.