Notice: On March 31, it was **announced** that Statalist is moving from an email list to a **forum**. The old list will shut down on April 23, and its replacement, **statalist.org** is already up and running.

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

From |
Carter Rees <carterrees@gmail.com> |

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

Subject |
Re: st: Generate variable seems to round numbers |

Date |
Fri, 30 Dec 2011 15:22:29 -0700 |

Thank you Lars. Your comment prompted me to do a little more digging. Stata gives me fair warning. -help data type- leads to the following comment. "Precision of numeric storage types floats have about 7 digits of accuracy; the magnitude of the number does not matter. Thus, 1234567 can be stored perfectly as a float, as can 1234567e+20. The number 123456789, however, would be rounded to 123456792. In general, this rounding does not matter. If you are storing identification numbers, the rounding could matter. If the identification numbers are integers and take 9 digits or less, store them as longs; otherwise, store them as doubles. doubles have 16 digits of accuracy." I'll have to be more careful. Hi Sorry for not giving you an aswere. This was discussed on this list a few days ago, but i cannot find the string on my phone. Its, as far as i remember, a presicions problem (se svend juuls book section 5.5 my copy is at my office) and something to do with how binary code is translated from and to string values. Mvh Lars Folkestad Den 30/12/2011 kl. 21.21 skrev "Carter Rees" <carterrees@gmail.com>: > As a follow-up, the new variable ALT_AID_NEW has a format of float %9.0g > before running the -tostring- command. > > > > Hi Statalist, > > > Working on a Mac Lion, Stata 12 MP4. > > > I am working with a data set that has variable ALT_AID stored as long > %10.0g. The variable is a unique identifier for a best friend the > respondent named on a survey. ALT_AID was originally stored as an 8 > character string variable but I used -destring- to get it to its present > format (I didn't specify a format, I let it set to the -destring- >default). > > My issue is this: If I want to create a duplicate of ALT_AID variable is > use the command: > > gen ALT_AID_NEW = ALT_AID > > The first case listed in my data set says ALT_AID has a value of >95576948. > When I look at the variable ALT_AID_NEW in the editor I see it stored as > 9.56e+07, clicking on the cell reveals a value of 95576944. If I use the > -tostring- command it returns an 8 character string variable with the >same > value of 95576944. As you can see, my unique identifier is now off by 4 > places in the new variable. This is happening in other cases as well with > numbers being off by 2 to 4 places. > > I am wondering if this is supposed to be happening and I simply need to > pay closer attention to formatting decisions in the future. Or, is there > something amiss with how this being handled in Stata? > > Thank you, > > Carter > > > * > * For searches and help try: > * http://www.stata.com/help.cgi?search > * http://www.stata.com/support/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/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/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/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**References**:**Re: st: Generate variable seems to round numbers***From:*Lars Folkestad <lfolkestad@health.sdu.dk>

- Prev by Date:
**st: marginsplot is acting differently** - Next by Date:
**st: FW: odds ratios/risk ratio: variables and levels of variable** - Previous by thread:
**Re: st: Generate variable seems to round numbers** - Next by thread:
**st: marginsplot is acting differently** - Index(es):