Different colname rules in ologit's r(table) and result to variable cut1 not found

[Chen Samulsion]

Dear Stata users,

I'm using -brant- command wrote by J. Scott Long & Jeremy Freese. Under Stata 16, when I run brant after performing ologit, it report an error saying that "variable cut1 not found". I checked the source of this error, and found that it is caused by _rm_modelinfo2 and _rm_rhsnames which are used to handle rhs information of ologit and provide them to brant. And because of different colname rules in ologit's r(table), the "_cons" is now named "cut1" "cut2" "cut3"... (see code below for detailed information), the _rm_rhsnames cannot change occurrences of "_cons" to " ". I think I have found a solution, i.e. to replace all the "cut1" "cut2" "cut3"... to " ". However, the problem is when I manipulate subinstr local, how can I change all occurrences of "cut1" "cut2" "cut3"... using a wildcard? As I show in below, the using of wildcard of * failed. Thank you very much.

local RHSnmsALL : subinstr local RHSnmsALL "cut*" " ", all

. version 13: quietly ologit class age income, nofvlabel

. matrix list r(table)

r(table)[9,5]
             class:      class:       cut1:       cut2:       cut3:
               age      income       _cons       _cons       _cons
     b   .01762786    .0135035  -1.1222525   1.7869218   5.6260597
    se   .00158518   .00048171    .0891443   .08476514   .13338274
     z    11.12045   28.032162          .b          .b          .b
pvalue   9.977e-29   6.59e-173          .b          .b          .b
    ll   .01452098   .01255936  -1.2969721   1.6207852   5.3646343
    ul   .02073475   .01444765  -.94753284   1.9530585   5.8874851
    df           .           .           .           .           .
  crit    1.959964    1.959964    1.959964    1.959964    1.959964
 eform           0           0           0           0           0


. version 15: quietly ologit class age income, nofvlabel

. matrix list r(table)

r(table)[9,5]
             class:      class:          /:          /:          /:
               age      income        cut1        cut2        cut3
     b   .01762786    .0135035  -1.1222525   1.7869218   5.6260597
    se   .00158518   .00048171    .0891443   .08476514   .13338274
     z    11.12045   28.032162          .b          .b          .b
pvalue   9.977e-29   6.59e-173          .b          .b          .b
    ll   .01452098   .01255936  -1.2969721   1.6207852   5.3646343
    ul   .02073475   .01444765  -.94753284   1.9530585   5.8874851
    df           .           .           .           .           .
  crit    1.959964    1.959964    1.959964    1.959964    1.959964
 eform           0           0           0           0           0

[Richard Williams]

You are probably making this much harder than it needs to be (but if so, several others have made the same mistake).

I think there are at least three versions of brant around. The most current is

. which brant
c:\ado\plus\b\brant.ado
*! version 4.0.0 2017-08-23 | long freese | stata 15 parameter naming fix

If that isn't the version of brant that you have, uninstall it. You want the version that comes packaged with Long & Freese's spost13 set of routines.

search spost13_ado

If that doesn't solve the problem, provide a replicable example (e.g. use auto or another data set anyone can access.)

[Chen Samulsion]

Thank you very much Richard Williams. My brant command is not updated.

. which brant
c:\ado\plus\b\brant.ado
*! version 3.3.0 2014-02-14 | long freese | spost13 release

P.S. after checking the new brant command, I find that the authors inserted a piece of new code:

    * 4.0.0 2017-08-23 stata 15 parameter naming fix
    if (_caller()>=15) version 15: _rm_modelinfo2
    else _rm_modelinfo2

[Richard Williams]

As a sidelight, you may have already a perfectly fine solution -- run ologit specifying version 13:

User-written postestimation commands, even if they are well written, can still get zapped if the estimation command they are used with changes the format of what it returns. Long and Freese updated their code to deal with the changes in ologit. But, if they had not done that, the old version of brant would probably still work if you specified version 13: when using ologit.

[Richard Williams]

Another sidelight -- whenever something seems to be buggy, one of the first things I do is update Stata and update my user-written ado files:

update all
adoupdate, update

If I am lucky, the problem has already been fixed. And if I am not lucky, at least I have the most up to date versions of everything.

NOTE: If you are using an old version of Stata, I suppose you have to be careful with adoupdate, as an updated version may require a newer version of Stata than you have.

A few years ago, somebody reported a bug in my gologit2 program. Indeed, there had been a bug ... but it got fixed in 2007. Getting the most current version of the program took care of things.

[Chen Samulsion]

Professor, yes, I add version 13 control before ologit. I open this thread because I don't want to add version control every time I run brant.
Crossed with #5: Actually, I have explored your gologit2 command these days. And I learn a lot from it and from https://www3.nd.edu/~rwilliam/gologit2/tsfaq.html. And thank you.