Statalist The Stata Listserver

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

RE: st: trim spaces in postcode

From   "Nick Cox" <[email protected]>
To   <[email protected]>
Subject   RE: st: trim spaces in postcode
Date   Sun, 2 Apr 2006 16:50:19 +0100

I have two guesses here. 

First, -generate- can be smart because
Stata can look at the expression on the RHS of 

gen newvar = exp 

and work out what kind of beast it is. What is more,
Stata is always going to be correct on this, or else
you are asking for something illegal. 

Second, -input- and -infile- historically weren't designed 
to be smart because it was thought that the user
could and should specify what variable types were wanted. 
-insheet- came a fair while later and was more ambitious. 
It peeks at the first and second lines of the file and
tries to work out what is going on. Often, it can misunderstand, 
which is part of the rationale for -destring- and -tostring-,
which came a wave later yet. 

In short, -infile- and -input- remain as originally designed 
on the principle of not fixing what isn't broken. 

[email protected] 

Ronnie Babigumira

> Yes I have used and continue to use -insheet- (mainly if I 
> have tab delimited data from excel) and specifying the string 
> length is not a problem with -insheet-. That said, there are 
> situations where -infile- is the appropriate command and of 
> course -input- is invaluable when I want to input a few 
> entries. In this case I have to specify the length of string 
> variables
Ada Ma 

> > have you tried -insheet-??

Ronnie Babigumira

> > Is there something in newer versions of Stata that would 
> save me from guessing the length of strings when using -infile-
> > and -input- 

*   For searches and help try:

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