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
[email protected]
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/
