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.
Nick
[email protected]
Hau Chyi
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
example.
Here is only one observation with one variable, which looks like below
in the asc file.
1234567890123456
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;
and then:
-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
100 kids!!
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
correct.
Thanks for calrifying. I'd also like to add that reading all the
questions and answers posted on the list has improved my own knowledge
to Stata tremendously.
Hau
> test.asc is a file of 10 individuals; and the .do file is machine generated file by the SIPP to infix them into Stata.
>
> The last variable of each individual is SSUID (at position 12654 - 12666) , the survey unit id.
> Tthe raw file indicates SSUID for the first six individuals to be:
> 019003754630
> 019003754630
> 019003754630
> 019003754630
> 019003754630
> 019033358630
>
> But after using the do file provided by SIPP website to -infix- them, the first 6 observations of the SSUID variable becomes:
> SSUID
> 19003754496
> 19003754496
> 19003754496
> 19003754496
> 19003754496
> 19033358336
>
> I've noticed that if I do -infix double SSUID- rather than -infix SSUID-, the problem will be fixed. Is this a bug of Stata or my computer? I've checked this problem on Stata 9 and Stata 10MP on PC.
>
> Thanks for calrifying. I'd also like to add that reading all the questions has improved my own knowledge to Stata tremendously!
*
* 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/
