Closed dreistein543 closed 2 years ago
benjann
commented
2 years ago Hi, thanks for reporting this. Seems to be a bug. I have no idea why order() and indicate() get in conflict with each other once you specify unstack, but I will try to look into this. Might take a while. ben
dreistein543
commented
2 years ago Hi, thanks for reporting this. Seems to be a bug. I have no idea why order() and indicate() get in conflict with each other once you specify unstack, but I will try to look into this. Might take a while. ben
it seems incomprehensible that this conflict between order() and indicate() with specification of unstack only when I try to output it with a result computed by reg. that is to say, if I store the results of ivprobit twice and output them together, this conflict won't happen.
so I suggest that this problem may occur when someone trying to output multiequation result and single-equation result together
NilsEnevoldsen
commented
2 years ago Here's a simpler replication indicating that something is going wrong even without indicate(). Note the equation names in the third and fourth estout. Maybe the equation named / is tripping up estout somewhere.
*ssc install estout, replace
version 16.1
sysuse auto, clear
eststo m1: regress weight length
eststo m2: ivprobit foreign (weight = length)
* correct
estout m1 m2, order(weight)
* correct
estout m1 m2, unstack
* incorrect
estout m1 m2, unstack order(weight)
* also incorrect
estout m2 m1, unstack order(weight)Relevant output:
. * correct
. estout m1 m2, order(weight)
--------------------------------------
m1 m2
b b
--------------------------------------
main
weight -.0015013
length 33.01988
_cons -3186.047 3.643953
--------------------------------------
weight
length 33.01988
_cons -3186.047
--------------------------------------
/
athrho2_1 -.0124362
lnsigma2 5.522311
--------------------------------------
.
. * correct
. estout m1 m2, unstack
----------------------------------------------------------------
m1 m2
_ foreign weight /
b b b b
----------------------------------------------------------------
length 33.01988 33.01988
weight -.0015013
athrho2_1 -.0124362
lnsigma2 5.522311
_cons -3186.047 3.643953 -3186.047
----------------------------------------------------------------
.
. * incorrect
. estout m1 m2, unstack order(weight)
----------------------------------------------------------------
m1 m2
_ foreign foreign weight
b b b b
----------------------------------------------------------------
weight -.0015013 -.0015013
length 33.01988 33.01988
athrho2_1
lnsigma2
_cons -3186.047 3.643953 3.643953 -3186.047
----------------------------------------------------------------
.
. * incorrect
. estout m2 m1, unstack order(weight)
----------------------------------------------------------------
m2 m1
foreign weight / _
b b b b
----------------------------------------------------------------
weight -.0015013
length 33.01988
athrho2_1 -.0124362
lnsigma2 5.522311
_cons 3.643953 -3186.047
----------------------------------------------------------------This may well be as estout has been written long before things such as equation names equal to "/" appeared in Stata :)
A (somewhat tedious) workaround is to rename the equations:
. estout m1 m2, unstack order(weight) equations(eq1 = 1:1, eq2 = .:2, eq3 = .:3)
----------------------------------------------------------------
m1 m2
eq1 eq1 eq2 eq3
b b b b
----------------------------------------------------------------
weight -.0015013
length 33.01988 33.01988
athrho2_1 -.0124362
lnsigma2 5.522311
_cons -3186.047 3.643953 -3186.047
----------------------------------------------------------------Note that the new equation names must be different from the names already existing in the models (e.g. you could not use weight for the second equation).
benjann
commented
2 years ago ok, the trouble is not "/", the trouble is the empty equation name in m1. This makes order() fail. So it seems to me that this is a problem that has been always there and I am surprised that it has not come up earlier. Once you make sure that the equation has a name, everything works fine.
. estout m1 m2, unstack order(weight) equations(1)
----------------------------------------------------------------
m1 m2
#1 #1 weight /
b b b b
----------------------------------------------------------------
weight -.0015013
length 33.01988 33.01988
athrho2_1 -.0124362
lnsigma2 5.522311
_cons -3186.047 3.643953 -3186.047
----------------------------------------------------------------or, for example,
. estout m1 m2, unstack order(weight) equations(main = 1)
----------------------------------------------------------------
m1 m2
main main weight /
b b b b
----------------------------------------------------------------
weight -.0015013
length 33.01988 33.01988
athrho2_1 -.0124362
lnsigma2 5.522311
_cons -3186.047 3.643953 -3186.047
----------------------------------------------------------------Reason why the problem only occurs when specifying unstack: If unstack is not specified, the default behavior is to match (the first equation of) m1 automatically with the first equation of m2 and name it main. If unstack is specified, matching equations is skipped so that the equation in m1 remains unnamed.
benjann
commented
2 years ago I now posted a fix. The subroutine implementing order() now temporarily replaces empty equation names with a tempname so that order() will not make a mess. Results are now correct for Niels' first "incorrect" example:
. estout m1 m2, unstack order(weight)
----------------------------------------------------------------
m1 m2
_ foreign weight /
b b b b
----------------------------------------------------------------
weight -.0015013
length 33.01988 33.01988
athrho2_1 -.0124362
lnsigma2 5.522311
_cons -3186.047 3.643953 -3186.047
----------------------------------------------------------------The second "incorrect" example by Niels will still be incorrect, but this has nothing to do with order(). Results will also be incorrect without order():
. estout m2 m1, unstack
----------------------------------------------------------------
m2 m1
foreign weight / _
b b b b
----------------------------------------------------------------
weight -.0015013
length 33.01988
athrho2_1 -.0124362
lnsigma2 5.522311
_cons 3.643953 -3186.047
----------------------------------------------------------------That is, also unstack seems to have problems with unnamed equations in some situations. I did not look into this yet.
NilsEnevoldsen
commented
2 years ago The second "incorrect" example by Niels will still be incorrect, but this has nothing to do with
order().
Interesting. Sorry for not noticing this.
benjann
commented
2 years ago Don't be sorry. You helped identifying a bug.
benjann
commented
2 years ago I now posted an update that also fixes the second issue reported by Nils.
. estout m2 m1, unstack order(weight)
----------------------------------------------------------------
m2 m1
foreign weight / _
b b b b
----------------------------------------------------------------
weight -.0015013
length 33.01988 33.01988
athrho2_1 -.0124362
lnsigma2 5.522311
_cons 3.643953 -3186.047 -3186.047
----------------------------------------------------------------Both issues were related to the fact that rownumb() interprets "_:" as "any equation". I now added a routine to estout that mimics the functionality of rownumb() but treats "_:" as distinct equation name. This routine is now also used to handle the first issue above. (Potentially, there are further instances of rownumb() in the code of estout that should be replaced by the new routine, but I am hesitant to do this without need because there is some cost in terms of speed.)
Note that the update does not fix all issues related to unstack; there are other ways how you can break it. My impression, however, is that these are very unlikely cases so I did not start trying to fix them.
benjann
commented
2 years ago Potentially, there are further instances of
rownumb()in the code ofestoutthat should be replaced by the new routine, but I am hesitant to do this without need because there is some cost in terms of speed.
... and also because I am unsure whether in some of these instances the default rownumb() behavior is actually more appropriate.
benjann
commented
2 years ago I now posted another update that undoes the previous fix and implements a more general approach to solve the problem. This also fixes a number of other issues. As noted above, the trouble is that Stata's rownumb() interprets equation specification "_" as any equation, but at the same time "_" is technically used by Stata as the name of an unnamed equation. In cases where the collected table of results contained both unnamed and named equations this could lead to various issues (such as the ones above; although many of them were not very likely to occur). I now changed estout so that it renames unnamed equations internally to "__"; this solves these problems because "__" is interpreted as a specific equation by rownumb() and not as any equation. The renaming is only done internally and is undone at the end. A plus of the new approach is that users can now specify "_:coef" in options such as drop(), keep() etc. to address coef only in the unnamed equation; before this was not possible as"_:coef" addressed coef in any equation. A minor disadvantage of the new approach is that if a model actually names an equation as "__" then estout will treat this as an unnamed equation; to my knowledge, no official Stata commands use "__" as equation name.
I tried to carefully check all options and functionalities for which the change of "_" to "__" matters, to make sure that I did not break anything and everything works fine. Naturally, there is no guarantee that the change did not introduce any new issues.
NilsEnevoldsen
commented
2 years ago @benjann This is (re-)fixed in 3.30, which is available on SSC. It would be appropriate to close this issue.
The
estoutpackge is amazing and it helps me a lot when I doing my research.however, when I try to output my analysis result computed by
regress&ivprobitwithmleestimation, something occurs.it is because
esttabcannot ouput r-square for the first-step result ofivporbit(p.s.mleestimation does not use two-step but the usage of "first-step" makes my issue more clearly and simply), I put a regression of first-step manually and try to out put them together useesttab.however, when I use
indicateorderandunstacksimultaneously, all Factor variables display "No". If I use them separately, the result displays well.I will show you my commands and a sample of my data to ensure the problem replication.
command I use list as follows
sample of my data as follows