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

From |
ariley@stata.com (Alan Riley) |

To |
statalist@hsphsun2.harvard.edu |

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

Date |
Wed, 02 Nov 2005 15:09:02 -0600 |

"HL" (hiorlow@sbcglobal.net) asked about subscripting variables when assigning values to macros or scalars. He tried to assign a subscripted value from a variable to a scalar and was surprised that it appeared to assign the first value of the variable to the scalar rather than the subscripted value. He saw this when he later tried to display the value in the scalar. I include his email below my signature for reference. In fact, the correct (subscripted) value was assigned to the scalar. The problem is that the scalar name he chose was also valid as a minimum abbreviation of a variable name. Variable names (even minimum abbreviations of variable names) take precedence over scalars in expressions. For example . sysuse auto . scalar mpg = 1 . display mpg 22 Why did that display "22"? It is because what is being displayed is NOT the value of the scalar 'mpg'. It is the value of the first observation of the variable 'mpg'. Stata first checked to see if what was in the expression after -display- was a variable name. It was, and so that trumped the scalar that existed with the same name. A -scalar list- will show that the scalar 'mpg' does exist with the correct value in it: . scalar list mpg = 1 In HL's example, he had a variable 'year' and a variable 'unemp'. He tried this: . scalar y=unemp[5] . di y 1986 He was expecting to see '6.3' which is the value of the 5th observation of 'unemp'. However, he instead saw the first value of the variable 'year'. This happened because 'y' was the minimum unique abbreviation for the variable 'year' in his dataset. The following would have worked: . scalar y=unemp[5] . set varabbrev off . di y 6.3 When using scalars, one should be careful that the scalars have unique names which are not abbreviations of any variables in the dataset. Alan (ariley@stata.com) > 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". <end> * * 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:
**st: RE: Brackets: ok for macros, very bad for scalars** - Next by Date:
**RE: st: Regressing with variables with missing values** - Previous by thread:
**st: Brackets: ok for macros, very bad for scalars** - Next by thread:
**st: RE: Brackets: ok for macros, very bad for scalars** - Index(es):

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