Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

st: RE: Precision

From   "Nick Cox" <>
To   <>
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. 


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:

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