![Statalist](/includes/images/head_statalist.jpg) |
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]
st: Re: infix problem?
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
http://ideas.repec.org/e/pba1.html
An Introduction to Modern Econometrics Using Stata:
http://www.stata-press.com/books/imeus.html
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.
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.
*
* 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/