Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: How blanks are treated when vars are read in as string froman ASCII raw data file

From   Ian Watson <>
Subject   Re: st: How blanks are treated when vars are read in as string froman ASCII raw data file
Date   Thu, 24 Nov 2005 19:48:31 +1100


I just thought of a simple test, which seems to confirm that infile and substr produce different results.

Using the substr approach (in yesterday's post):

. list if num==" 1"

| v1 alpha num |
1. | B 1 B 1 |

Using your infile approach:

. list if siteid==" 1"

ie. nothing.

In other words, infile is stripping out the leading blanks.

Kind regards,

Ian Watson
Senior Researcher
acirrt, University of Sydney
NSW, 2006, Australia

phone: 02 9351 5622

Ian Watson wrote:


I've reproduced your problem and compared it with yesterday's solution and can only come up with one suggestion.

When you infile the string and then split it, using the substr function, the right hand component (which I called num in yesterday's post) has leading blanks on it. These are then replaced by leading 0s using the subinstr function.

However, when you infile the string as two strings, Stata possibly strips the leading blanks from it. Even though it has the designation of a str3 type, it may not have the same "contents" as num did (which was also a str3 type) because that latter was created from substr. That
is " 23" and "23" look the same on the screen, but they're not the same data.

This is only a guess, and I can't find an easy way to test it. But it suggests you're better off reading your string in as a full string, then splitting it, rather than as two strings. At least that works (even if the reason is not altogether clear to me why).

*   For searches and help try:

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