How to add support for -margins- in a user-written command?

[Sergio Correia]

I'm looking for a way to add support to -margins- (a postestimation command) in reghdfe (an estimation command available in SSC). This has been on my to-do list for a while (discussion), but I can't find anything relevant on the manuals, or help files (not even in "help undocumented") so I'm not sure how to proceed.

I found some useful hints in the Stata 11 announcement, but I'm still not sure what should I include in e(marginsok) and in the other macros listed below.

Does anyone know anything about these options?

Thanks,
Sergio


Attaching excerpt from the announcement:

Estimation commands now post in macros how new command margins is to treat their prediction statistics when the statistics require special treatment. These macros are e(marginsok), e(marginsnotok), and e(marginsprop).

e(marginsok) specifies the name of predictors that are to be allowed and that appear to violate margins’ usual rules, such as dependent variables being involved in the calculation.

e(marginsnotok) are statistics that margins fails to identify as violating assumptions but that do and should not be allowed.

e(emarginsprop) provides special signals as to how statistics for the estimator must be handled. Currently allowed are combinations of addcons, noeb, and nochainrule. addcons means that the estimated equations have no constant even if the user did not specify noconstant at estimation time. noeb means that the estimator does not store the covariate names on the name stripe of e(b). nochainrule means that the chain rule may not be used to calculate derivatives.

[Richard Williams]

Do you have a predict command? That is one of the biggest things you need.

Have you tried margins with it as is? If all you need is xb, margins might already work.

[William Lisowski]

I note that the PDF documentation for ereturn includes the following.

buildfvinfo specified with ereturn post or ereturn repost computes the H matrix that postestimation commands contrast, margins, and pwcompare use for determining estimable functions.

[Sergio Correia]

Do you have a predict command? That is one of the biggest things you need.

I have a predict command that works (with mostly the same options as areg) and has its own set of certification scripts that all pass. But when I used margins and compared it with areg, it gave me the wrong results so there must have been something missing.

I went through a bit of tutorials, including your article and slides, but I'm still at a loss about how it works behind the scenes (and in what cases it doesn't work).

I note that the PDF documentation for ereturn includes the following.

I do have that although I'm not sure how/why did I end up with that in my ereturn post line:

ereturn post `b' `V', `esample' buildfvinfo depname(`depvar')

Thanks!
S

[Richard Williams]

I've added margins support to oglm and gologit2. I don't remember it as being that big of a deal. You can search the code for references to margins, there aren't too many.

Maybe you could post the code for a replicable example where margins for areg and reghdfe disagree and you think areg is giving the right answer.

[Jeff Pitblado (StataCorp)]

Based on the examples provided in the "discussion" link provided by Sergio, it seems to me that margins is working properly after reghdfe.

Here are the examples.

sysuse auto

areg price c.weight##c.headroom, a(turn)
est store areg1
margins, dydx(weight) at(headroom=(1.5(0.5)5)) post
est store areg1_marg

reghdfe price c.weight##c.headroom, a(turn)
est store reghdfe1
margins, dydx(weight) at(headroom=(1.5(0.5)5)) post
est store reghdfe1_marg

* show equivalent model fits, and the same parameterization
est table areg1 reghdfe1, b se stat(rmse)

* show -margins- yields the same marginal effects and SE estimates
est table areg1_marg reghdfe1_marg, b se

areg price c.weight##i.foreign, a(turn)
est store areg2
margins for, dydx(weight) post
est store areg2_marg

reghdfe price c.weight##i.foreign, a(turn)
est store reghdfe2
margins for, dydx(weight) post
est store reghdfe2_marg

* show equivalent model fits, but a different parameterization because
* the c.weight#1.foreign coefficient was fit by -areg-, but
* c.weight#0.foreign was fit by -reghdfe-
est table areg2 reghdfe2, b se stat(rmse)

* show -margins- yields the same marginal effects and SE estimates
est table areg2_marg reghdfe2_marg, b se

The only discrepancy I see is that reghdfe is dropping a different coefficient due to collinearity.

[Richard Williams]

* show equivalent model fits, but a different parameterization because
* the c.weight#1.foreign coefficient was fit by -areg-, but
* c.weight#0.foreign was fit by -reghdfe-

Note that you can get rid of even that small discrepancy by changing the 2nd reghdfe command to

reghdfe price c.weight##1.foreign, a(turn)

[Richard Williams]

Sergio's original code from that discussion was

clear all
cls
sysuse auto  
reghdfe price weight i.foreign, a(turn)
margins foreign  
areg price weight i.foreign, a(turn)
margins foreign

The two margins commands do indeed provide different adjusted predictions, so I can see why Sergio thinks his command is not working right. But if I ask for the marginal effects instead,

clear all
cls
sysuse auto  
reghdfe price weight i.foreign, a(turn)
margins r.foreign  
areg price weight i.foreign, a(turn)
margins r.foreign

the marginal effects from both models are the same.

I don't understand either command well enough to explain the differences in adjusted predictions. But the manual says "areg begins by recalculating depvar and indepvars to have mean 0 within the groups specified by absorb()." So I imagine that has something to do with the differences in adjusted predictions.

[Sergio Correia]

Hi Jeff, Richard,

Thanks for the detailed replies, they are incredibly useful!

I think I pinpointed the issue. reghdfe does not include the constant within Xb , as it just includes into the "d" component (y = Xb + d + e) and that creates these issues. This also explains why the marginal effects work, but the average values (that depend on the constant) don't.

I have a workaround in mind that should make it easier to add the constant into Xb and this fix the problem)

Cheers,
Sergio

[Sergio Correia]

Just for a quick update, I just added support for margins, and it was as Richard mentioned, relatively straightforward, once I knew that predict,xb had to include the constant. Again, many thanks Jeff, Richard and William for your helpful advice!