[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: Precision |

Date |
Fri, 11 Nov 2005 14:36:57 -0000 |

I think you are confusing some or all of three distinct things: 1. The detail you see when you look at a number (or something that can be interpreted as such) outside Stata: this could be on a sheet of paper or other medium, or in another program. In particular, you can see a large number of decimal places, but that doesn't mean that Stata (for example) will necessarily be able to hold an absolutely exact representation of what you see, because of 2. The precision with which that number (or ...) is held internally within memory by Stata. This hinges on two facts, one partly under your control and one not. What is under your control (partly) is the scope for using appropriate data types (-double- or -long-) when needed. What is beyond your control is the fact that a binary representation is used for numbers you think of as decimal, which leads to occasional small problems that have been well documented by StataCorp. Quite separate is 3. The format, which is how that number is displayed in results. Applying a format does nothing whatsoever to change how the number (or ...) is held, and in particular it can never restore precision that has been lost earlier. That's like trying to get the toothpaste back in the tube. It follows that applying a format is quite different from -destring-ing a numeric variable. -destring- could have been written to include a -format()- option to do that along with the conversion, but it wasn't. I can't remember precisely why I didn't do this when I first wrote -destring-, but my rationale should have been that it is a different issue -- and in any case different variables might well need different formats. More importantly, StataCorp did not think it appropriate to add a -format()- option when -destring- was made an official command. -format-ting is quite a separate issue from entering data. In your case one concrete action that should help is to use -double- whenever precision is your concern. But with large numbers of decimal places, and numeric representations, some very small losses are pretty much inevitable. %9.11f is an invalid format, as the number of decimal places cannot exceed the width of the field allocated for display. Nick n.j.cox@durham.ac.uk Ronnie Babigumira > I have scanned some of the previous posts on this subject but I am not > making any headway. > > I have text file with two variables whose contents are 16 > digit numbers of the form > > x > 348080.2688552010 > > I would like to import the data into stata whilst maintainig the > precision. Here is what I have done. I import the variables as strings > and that works. However, the next challenge is that they need > to be used as numeric variables (this is the hair loss part). I have tried > > gen y = real(x) > destring x, gen(y) > > Both dont have an option to specify the format. Trying to format the > generated variables also wont help since format y %9.11f gives me the > dreaded red lines and blue lines > > invalid %format > r(120); > > So my question is how can I change x from string to numeric whilst > maintaining the precision. Or even better, how best can I import this > into stata as a numeric variable without loss of precision. * * 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: Minimum of a vector or a matrix.** - Next by Date:
**st: xttest2 problem** - Previous by thread:
**st: RE: Precision** - Next by thread:
**st: Minimum of a vector or a matrix.** - Index(es):

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