Nick alluded to my recent troubles with scalars. The issue is quite
nicely discussed in a Stata Tip in the very latest issue of the Stata
Journal (you do subscribe, don't you?) by Gueorgui I. Kolev in
http://ideas.repec.org/a/tsj/stataj/v6y2006i2p279-280.html
The problem arose in the levinlin routine. A researcher was getting a
peculiar "no observations" error when calling the test in
circumstances that suggested she should have no problem with the
routine. It turned out that the researcher has a variable "casenum"
in her dataset. When Fabian Bornhorst and I wrote levinlin, we used
"scalar case" to distinguish between various cases determined by
options. Due to Stata's annoying habit of by default allowing
abbreviations of variables to be used, a statement such as
if case == 1 {
...
examined not the scalar case, but the FIRST OBSERVATION of the
variable casenum, which (fortunately!) did not happen to coincide
with any of the values we were expecting. Unfortunately, we did not
test for that circumstance in the code.
There are several ways of avoiding being bitten by this bug. The best
IMHO is to use a tempname for scalars that are local to a program.
(We also could have specified in the if statement that we were
referring to the scalar case, but that is rather clumsy). Even if the
abbreviation setting was disabled, a user variable named "case" would
have caused this problem.
This is a rather nasty bug to diagnose -- easy enough to fix, but
somewhat tricky to locate. The best way to avoid it is to use
temporary names (and temporary variables, for that matter) when the
object should have ephemeral existence.
Best wishes of the summer (or winter!) solstice to all--
Kit Baum, Boston College Economics
http://ideas.repec.org/e/pba1.html
*
* 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/
