[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
st: Re: infix problem?
Kit Baum <email@example.com>
st: Re: infix problem?
Wed, 14 May 2008 10:10:03 -0400
But even with a double declaration you cannot read 16 digits and retain them all. This is beyond the capability of a double data type. You should use a string variable type to deal with a 16-character ID code properly, as is often discussed on this list. Even if an ID is numeric, there is no downside to treating it as string, and will ensure that this kind of problem does not bite you.
Kit Baum, Boston College Economics and DIW Berlin
An Introduction to Modern Econometrics Using Stata:
On May 14, 2008, at 02:33 , Nick wrote:
This is arguable. The help of -infix- does indicate that if you want a -double- you need to specify that, so Stata is putting the onus on you to think about variable types.
Otherwise put, your punishment is that you got what you asked for.
Despite that, the idea that Stata should be smart on your behalf is naturally attractive. Quite what that would mean with -infix- is not clear except to Stata developers who know the exact algorithm. In particular, a decision on optimal variable types presumably implies two passes through the data, i.e. the field width is not enough to decide.
I've downloaded several variables from the SIPP (Study of Income and
Program Participation), and realized there seems to be a problem with
the -infix- command, which I hope can be illustrated by the following
Here is only one observation with one variable, which looks like below
in the asc file.
This is the SSUID, the survey unit id of each individual.
If you save this into a asc file as, say "d:\documents\test\test.asc"
, and run the following lines:
infix SSUID 1-16 using "d:\documents\test\test.asc";
format SSUID %16.0f;
- -list SSUID-
The variable Stata reads is:
| SSUID |
1. | 1234567948140544 |
It's completely wrong! I realize this after discovering some families
I generated from SSUID (and other family identifyers) have more than
The problem disappears when I do
- -infix double SSUID 1-16 using ... -
In other words, the precision -infix- chooses automatically is wrong.
Is this a bug of infix or some memory allocation error of my computer?
No matter what, I recommend if you are infixing variables with more
than 10 digits, you'd better check the ascii file to see if it's truly
* For searches and help try: