I just ran across such a data set today. It had characteristics for a few hundred lottery games. The color described the ticket colors. There were a few other string variables that also could have observations that were comma-delimited lists. Moreover, the comma-delimited lists could include values that did not show up as unique values in other observations (like "yellow" in the example above).

So I thought I'd write a program that could deal with all of that without the need of any visual inspection or case-by-case manual labor on my part. I wanted it to be applicable to any string variable in this situation. My suggestion is below:

// ##### getDummies -- turns string to dummies. Takes one argument:
// ##### `1' -- string, the name of the variable of interest.
capture prog drop getDummies
prog def getDummies

local stringvar `1'
quietly count
local fullset=r(N)
quietly count if !regexm(`stringvar',",")
local uniques=r(N) // cases where `stringvar' is not a list

if `fullset'!=`uniques' {
  quietly {
    tab `stringvar' if regexm(`stringvar',",")
    levelsof `stringvar' if !regexm(`stringvar',","), local(tags)
    preserve
    tempfile `stringvar'_lists
    keep `stringvar'
    keep if regexm(`stringvar',",")
    duplicates drop
    split `stringvar', p(",")
    save "``stringvar'_lists'", replace
    restore
    describe `stringvar'* using "``stringvar'_lists'", varlist // note(1)
    local `stringvar'_stubs=r(varlist)
    split `stringvar', p(",")
    local stubs: list sizeof `stringvar'_stubs
    forvalues i=2/`stubs' {
      local stub: word `i' of ``stringvar'_stubs'
      replace `stub'=trim(`stub') // note (2)
      levelsof `stub' if `stub'!="", local(extras)
      local tags: list tags | extras
    }
    local tags: list sort tags
  }
}
else {
  di "for each value of `stringvar' there corresponds one dummy variable"
  capture drop __*
  quietly levelsof `stringvar' if !regexm(`stringvar',","), local(tags)
  local `stringvar'_stubs `stringvar'
}
capture drop __*

local stubnum: list sizeof `stringvar'_stubs
local tagnum: list sizeof tags

quietly {
  forvalues i=1/`tagnum' {
    local thistag: word `i' of `tags'
    local thistag: list clean thistag
    gen byte _`stringvar'_`i'=0
    forvalues j=1/`stubnum' {
      capture drop __*
      local thisstub: word `j' of ``stringvar'_stubs'
      replace _`stringvar'_`i'=1 if `thisstub'=="`thistag'"
    }
  }
}
drop `stringvar'*

// this section is for listing stuff on screen and in the log
local `stringvar'_stubs: list `stringvar'_stubs-stringvar
local stubs: list sizeof `stringvar'_stubs
di ""
di "total number of games: `fullset'"
di "number of games where `stringvar' is not a list: `uniques'"
di "unique values of `stringvar': `tagnum'"
if `stubs'>0 {
  di "where `stringvar' is a list, it is this long at most: `stubs'"
}
di ""
forvalues i=1/`tagnum' {
  local thistag: word `i' of `tags'
  local thistag: list clean thistag
  di "_`stringvar'_`i' is for `stringvar' == `thistag'"
}

end


That's it. This program collects all the possible values that your stringvar can take, whether inside comma-delimited lists or by themselves, and produces accurate dummies that are equal to one every time such a value is encountered, whether by itself or in a list, and regardless of its position in the list. With your data set in memory, you simply call

getDummies color

Now, I don't post programs unless they contain something I just learned in the process of writing them. Today's such thing is in line 24, next to the comment "note(1)". Turns out -- if you call help describe -- there are two kinds of describe: one for data in memory, another for data using a file. The latter comes with a different set of options. One of them is varlist. It stores the name of the variables in r(varlist). I chose to preserve/restore and create the tiny temporary file "``stringvar'_lists'" so I could apply describe using to it, and get a variable list saved in the local ``stringvar'_stubs'. I'm using it later on.

This may look like a lot of work, and it is, but it's all up-front. You do it once, and if it works now it works forever. The marginal cost of creating dummies out of any number of such variables is zero from here on out.

Update (February 4, 2009): the first version of getDummies had a bug. The line marked with the comment "note(2)" was missing. As a result, the program produced more dummies than it should have.  To use my color example, without this line getDummies will produce two separate dummies for the color "blue": one for the case where color was equal to "blue" strictly, and another for the case where color contained the string " blue". Notice the leading blank space. You want to trim() it.

Packaging a set of commands inside a program, to be read once and then invoked as many times as they are needed, is nice enough. But what if you need to make those instructions apply to different variables in different instances?

For example, I have a set of parameter estimates for a survival model. I use them to calculate the lambda part of the hazard function under various scenarios for one variable of interest. You can do this immediately after estimating your hazard model, of course, using predict with appropriate modifiers, but you don't want to re-estimate the model every time you need to use the parameters. Besides, you may have to use one data set for estimating the model (say historical data) and other data sets (say current data) for making the predictions of interest.

So let's say that you have your parameters saved in a matrix, and declare a program, called e.g. getLambda, to pair them with the corresponding regressors as many times as you need to. But every time you call getLambda, instead of the first regressor you need to use a variable that is some sort of transformation of it, and you saved that variable with a different name to make it absolutely clear that this is not the actual regressor. It would be nice if you could pass that variable as an argument to getLambda, in effect telling Stata "I want to calculate lambda with this particular variable at the front of the regressor list this time".

The program getLambda might look something like this:


capture prog drop getLambda
prog def getLambda

local thiscase `1'
local myregressors "`thiscase' var1 var2 var3 1"
local regressorcount: list sizeof myregressors

forvalues i=1/`regressorcount' {
   local thisreg: word `i' of `myregressors'
   gen param_`i'=beta[`i',1]*`thisreg'
}
egen lambda_`thiscase'=rsum(param_1-param_`regressorcount')
drop p_*

end

I forced the last element of `myregressors' to be 1 because I am assuming that the constant is the last parameter saved in your parameter matrix. Notice the local `1' in the first line after the program definition. It is Stata's name for the first argument of your program. In our case, that argument is simply the name of the variable that you want in the first position in the regressor list. So the call to getLambda would be


getLambda foo

This would make Stata calculate the lambda with the variable foo at the front of the regressor list. If later you want the variable bar there instead, you just call

getLambda bar

Arguments can be strings, numbers, whatever. As long as your function is strictly for internal use and you know what you're using it for, you don't need to program the fancy stuff -- like error codes or help files. That, at least, is what I found. When I get to the point where I need those extras, I'll learn how to do them and then blog about it here.

You may have noticed the apparently superfluous use of the list sizeof extended macro function. After all, it's plain enough that the word count of the "myregressors" local is 4. Well, sometimes you have more regressors than that. Do you care to count them by hand? I don't.

There are all sorts of very good reasons for leaving to Stata as much of the grunt work as possible. The most obvious of them is that code written this way is more portable across different projects. But the honest truth is that I really like those list functions. I've been finding all sorts of uses for them lately. I am going to have a blog post dedicated to them sometime soon.