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

st: RE: bugs using _all

From   "Nick Cox" <[email protected]>
To   <[email protected]>
Subject   st: RE: bugs using _all
Date   Sun, 10 Jul 2005 22:30:38 +0100

The Statalist FAQ advises this: 

Don't say "Is this a bug?". Almost all the time, it is not! 

However, you have, I guess been bitten by something 
designed to protect you. 

When you type -logit-, you fire up a wrapper program
which, among other things, creates a temporary variable 
recording the sort order, so that your data can be 
left in their current sort order when -logit- is done. 

This temporary variable is thus part of _all when 
-logit- passes the ball. Evidently it is true that 
your data order are in the sort order of your response 
variable, so -logit- bails out for the reason given. 

This is fixable by StataCorp, although I am not 
sure how keen they will be to do it. The code to 
fix it is embedded within -egen.ado-, for which 
the fix is arguably more important. 

The easiest fix is just not to do this, in the way 
that you have demonstrated. In most circumstances, 
firing all the variables at a binary response is 
likely to be poor science. I guess in your case 
it just seemed a neat short-cut. 

I can't comment on your other cases not documented

[email protected] 

Jun Xu
> Could be that I missed something, but it might be a bug. I found that 
> sometimes, I will get weird results or simply refusal to 
> estimate a simple 
> logit model. For example (lfp is the first variable in the list),
> . logit _all
> outcome = __000000 > 325 predicts data perfectly
> r(2000);
> . logit lfp-inc

*   For searches and help try:

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