[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
Kit Baum <baum@bc.edu> |

To |
statalist@hsphsun2.harvard.edu |

Subject |
st: Re: infix problem? |

Date |
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

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

n.j.cox@durham.ac.uk

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/

**Follow-Ups**:**Re: st: Re: infix problem?***From:*"Hau Chyi" <hauchyi@gmail.com>

- Prev by Date:
**Re: st: minor problems with Statalist** - Next by Date:
**Re: st: multiple rolling regressions** - Previous by thread:
**st: Re: GMM or 2SLS with cluster adjustment or others** - Next by thread:
**Re: st: Re: infix problem?** - Index(es):

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