Notice: On April 23, 2014, Statalist moved from an email list to a forum, based at statalist.org.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

From |
Alfonso Sanchez-Penalver <[email protected]> |

To |
"[email protected]" <[email protected]> |

Subject |
Re: st: problem with addition in var generation |

Date |
Thu, 7 Nov 2013 06:32:03 -0500 |

Hi Nick, Does Stata then automatically convert a string variable into a numerical one when in an operation with the addition operator? I ask because otherwise how can tract have leading zeros if it is not a string? I have just downloaded your piece on strings and numbers (The Stata Journal (2002) 2, Number 3, pp. 314–329) and will read it. Thanks for your great comments as usual. Alfonso Sanchez-Penalver > On Nov 7, 2013, at 4:00 AM, Nick Cox <[email protected]> wrote: > > Andrew is adding numeric variables. Stata would not let you add a > numeric variable to a string variable without explicitly converting > one or the other to compatible data types. > > Nick > [email protected] > > > On 7 November 2013 04:22, Alfonso Sanchez-Penalver > <[email protected]> wrote: >> Hi Andrew, >> >> Correct me if I'm wrong. From your description I infer that tract is a string variable, otherwise it would not have a leading 0, so when generating fips you are trying to add a number to a string and expect Stata to figure out that even though tract is a string it ought to treat it as a number. I don't have much experience with how Stata deals with this, but I have vast experience programming in many different languages to know that that expectation is usually wrong. So I would not be surprised that Stata is not actually adding wrong, but rather that you at not telling Stata to perform a straight forward addition. My suggestion is that you convert tract to a numeric variable by using -encode- prior to generating fips and then go ahead and generate fips. If someone knows more about how Stata deals when adding strings and numbers or where to find some explanation about it I would love to learn about it. >> >> Best, >> >> Alfonso Sánchez-Peñalver, PhD >> >>> On Nov 6, 2013, at 10:39 PM, Andrew Hovel <[email protected]> wrote: >>> >>> Hello All, >>> >>> I am having issues with Stata performing simple addition when I create a >>> variable. I am using Stata 12 for windows. >>> >>> The issue is straight-forward on the face of it: Stata is adding >>> incorrectly. >>> >>> Background: >>> I am trying to construct pseudo fips codes by adding the tract code to the >>> 5 digit state-county fips. For instance, 06037 denotes Los Angeles County, >>> CA, so I would add 6037000000 to the six-digit tract fips code to form a 10 >>> digit code-- 11 digits for states later in the alphabet with fips id's >>> above 10. >>> I have two variables formatted %15.0f, fip11 and tract. tract is 6 digits >>> long and uniquely identifies the Census tracts in my dataset. >>> >>> .gen fip11 = 0 >>> .replace fip11 = 6001000000 + tract if T_COUNTY == "001" >>> .replace fip11 = 6037000000 + tract if T_COUNTY == "037" >>> .replace fip11 = 6073000000 + tract if T_COUNTY == "073" >>> >>> When I run this, I get something like this: >>> -tract- -fip11- >>> 400200 6001400320 >>> 400500 6001400320 >>> 400400 6001400320 >>> 400300 6001400320 >>> >>> This happens for others in ascending order. >>> >>> I noticed a trend in the way they are adding. Cases repeat values for fip11 >>> usually about 4 or 5 times in a row. After 4 or 5 cases, the value >>> increases by 512 each time. >>> >>> For example: >>> >>> -tract6- -fip11- >>> 400300 6001400320 >>> [3 cases] >>> 400100 6001400320 >>> 400900 6001400832 >>> [3 cases] >>> 400600 6001400832 >>> 401300 6001401344 >>> [3 cases] >>> 401400 6001401344 >>> 401800 6001401856 >>> [3 cases] >>> 401600 6001401856 >>> 402400 6001402368 >>> [3 cases] >>> 402200 6001402368 >>> 402900 6001402880 >>> >>> Has anyone seen this problem before? I have had this issue in the past. I >>> am guessing I must have some sort of setting wrong to cause the addition to >>> occur like this. >>> * >>> * For searches and help try: >>> * http://www.stata.com/help.cgi?search >>> * http://www.stata.com/support/faqs/resources/statalist-faq/ >>> * http://www.ats.ucla.edu/stat/stata/ >> >> * >> * For searches and help try: >> * http://www.stata.com/help.cgi?search >> * http://www.stata.com/support/faqs/resources/statalist-faq/ >> * http://www.ats.ucla.edu/stat/stata/ > > * > * For searches and help try: > * http://www.stata.com/help.cgi?search > * http://www.stata.com/support/faqs/resources/statalist-faq/ > * http://www.ats.ucla.edu/stat/stata/ * * For searches and help try: * http://www.stata.com/help.cgi?search * http://www.stata.com/support/faqs/resources/statalist-faq/ * http://www.ats.ucla.edu/stat/stata/

**Follow-Ups**:**Re: st: problem with addition in var generation***From:*Maarten Buis <[email protected]>

**Re: st: problem with addition in var generation***From:*Nick Cox <[email protected]>

**References**:**st: problem with addition in var generation***From:*Andrew Hovel <[email protected]>

**Re: st: problem with addition in var generation***From:*Alfonso Sanchez-Penalver <[email protected]>

**Re: st: problem with addition in var generation***From:*Nick Cox <[email protected]>

- Prev by Date:
**st: Problems with ml max Survival analysis** - Next by Date:
**Re: st: problem with addition in var generation** - Previous by thread:
**Re: st: problem with addition in var generation** - Next by thread:
**Re: st: problem with addition in var generation** - Index(es):