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

From |
"Nick Cox" <n.j.cox@durham.ac.uk> |

To |
<statalist@hsphsun2.harvard.edu> |

Subject |
st: RE: Brackets: ok for macros, very bad for scalars |

Date |
Wed, 2 Nov 2005 21:06:09 -0000 |

Surprise is in the mind of the beholder. Your surprise depends on the conjunction of several rules here: 1. Given a choice between interpreting something as a variable and that same something as a scalar with the same or equivalent name, Stata always goes for the variable, unless instructed otherwise. (That seems clear-cut. Variables are first-class citizens in Stataland; scalars are minor, ephemeral and dispensable.) 2. You can abbreviate variable names. Thus in your case "y" can mean "year". (We could argue whether that was a good decision, but too late now.) 3. Given a variable in a context where only a single value makes sense, Stata goes for the first observation. Thus . di varname always is taken to mean . di varname[1] (Same comment as above. Sure, that seems dopey when it bites you, but my guess (emphasise guess) is that Stata doing what you think it should would depend on Stata trying to work out what the user should mean, and that's hopeless as a route to software design. People's partners should be good at sensitive intuition, but people's programs should stick to syntax, not semantics or intentions.) I think there are three morals. (a) If you want to use scalars rather than locals, always use a tempname for every scalar. That's a little more complicated, but safer. In a proper program you really always should use tempnames to avoid possible clashes like this. (b) Or, or additionally, you can insist on the scalar interpretation by using -scalar()-. (c) Every non-trivial language bites if you can't see through all the implications of all the rules and almost none of us can. There could be a good article for the Stata Journal on the top twenty gotchas that bite like this, so part of the issue is just how prominently stuff like this is documented. Nick n.j.cox@durham.ac.uk D H > correct?) [Stata 8.2] > > To my surprise, using brackets to indicate observation > number works with local and global macros, but not > with the scalar command. > > As an example, consider the following dataset: > > . list > > +------------------------+ > | year unemp gdpgap | > |------------------------| > 1. | 1986 6.6 -.00888 | > 2. | 1987 5.7 .00569 | > 3. | 1988 5.3 .01402 | > 4. | 1989 5.4 .01267 | > 5. | 1990 6.3 -.01081 | > |------------------------| > 6. | 1991 7.3 -.02822 | > 7. | 1992 7.4 -.01411 | > 8. | 1993 6.5 -.01542 | > <snip> > > . global yy=unemp[5] > > . di $yy > 6.3000002 > > So far so good (ignoring the problem with the float > datatype). Now try the same with a scalar command: > > . scalar y=unemp[5] > > . di y > 1986 > > Here, Stata inexplicably appears to insert the upper > left hand observation from the dataset, which happens > to correspond to "year" rather than "unemp". > > The following will work properly though: > > . scalar z=unemp in 5 > > . di z > 6.3000002 > > Any comments? > > What if I want to make a scalar a function of two > different observations? (I suppose in the latter case > I could grab the observations with a local macro, then > insert the values into the scalar, but then I would > lose any precision or speed advantages of the scalar > method). > > As the fine manual notes, macros provide up to 13 > significant digits in scientific notation, while > scalars provide more. Macros are also somewhat > slower. If neither of these factors is especially > important, perhaps the casual programmer might want to > stick with macros. * * 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/

- Prev by Date:
**Re: st: Regressing with variables with missing values** - Next by Date:
**Re: st: Brackets: ok for macros, very bad for scalars** - Previous by thread:
**st: Brackets: ok for macros, very bad for scalars** - Next by thread:
**RE: st: Re: fitstat** - Index(es):

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