Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Marginsplot for omitted category

    Hi all,
    I'm estimating the heterogenous impacts (by gender) of a continuous treatment variable on an outcome. Here's a version of my regression model:

    Code:
    reghdfe y i.sex##c.treatment [controls], absorb(absorbvar) cluster(clustervar)
    I want to create a marginsplot that plots predicted values for both categories of sex over a range of treatment. I've tried out several iterations of the margins post-estimation command, but I'm running into an issue wherein I'm unable to get predicted values for the category of sex coded as 0 (in my case, males). Here are three versions that I've tried:

    Code:
    margins sex, at(treatment=(-1(1)1))
    Code:
    margins, at(sex=0 treatment=(-1(1)1)) at(sex=1 treatment=(-1(1)1))
    Code:
    margins, over(sex) at(treatment=(-1(1)1))
    They all give me the margins for sex=1, but not for sex=0 (the specific message is that it's not estimable), and as a result, the marginsplot is only plotted for sex=1. I would like to plot the margins for both categories of sex.

    Any help would be appreciated. Thank you!

  • #2
    I'll bet that if you look closely at your -reghdfe- output, before the regresion table, you will see a warning that looks something like this:
    Code:
    note: 1bn.sex is probably collinear with the fixed effects (all partialled-out values are close to zero; tol = 1.0e-09)
    This will happen if your absorbvar is some variable representing a person (or animal, or whatever) for which sex is a time-invariant property, which I'm guessing is the case in your situation. In that case, the marginal effects for sex are, as -margins- points out, inestimable in that model. So you are trying to get -margins- to do the impossible: your model is not capable of estimating the effects of time-invariant properties of the absorbed fixed effect. This is always true in fixed effect models: the fixed effect itself accounts for all unvarying properties of the units that the fixed effect represents, making the effects of those properties undefinable.

    Indeed, the mystery here is why you are getting marginal effects for sex = 1, as these are also not estimable in a fixed effects model and you should not be getting output for them from -margins-. (And do not use the outputs you are getting for sex = 1, as they are necessarily incorrect.)

    If your research goal requires you to estimate sex effects, then you must use some other kind of model such as a random effects model, or a hybrid model (see -xtreg, cre- if you are using version 18.5, or -xthybrid- from SSC if you are using an earlier version of Stata.)
    Last edited by Clyde Schechter; 08 Mar 2025, 18:33.

    Comment


    • #3
      Hi Clyde,
      Thanks for your response! The regression model is not absorbing individual fixed effects, but at a more aggregated level (in this context it's classroom fixed effects from a prior grade).
      So, the sex indicator is not omitted.

      Comment


      • #4
        OK, that's different. In this case, the inestimability of sex == 1 is most likely due to some level of absorbvar for which sex == 1 does not occur in the estimation sample (after observations containing any missing values for any model variable are omitted). Looking at -tab abosrbvar sex if e(sample)- will enable you to see if this is the case, and, if so, to identify the offending classroom(s).

        Comment


        • #5
          Clyde,
          sex==1 is always estimated- it's sex==0 where it's not estimated. The estimation sample precludes that possibility by design- it is constructed so as to have a minimum number of students of all genders within each classroom. I believe it's because of sex==0 being the baseline category; the same thing happens when I use a flipped version of the variable in the estimation (so males are inestimable when my sex variable codes males as 0 and females as 1, and females are inestimable when I code them as 0 and males as 1). The problem goes away when I use the "noestimcheck" option but I'm unclear about what the problems with that could be.
          Thanks!

          Comment


          • #6
            The problem goes away when I use the "noestimcheck" option but I'm unclear about what the problems with that could be.
            Yes, of course it does. But that's just like a -force- option. In fact, it is a force option, just with another name. And like all force options it does not solve any problem, it simply sweeps the problem(s) under the rug. Like -force- options, it is only safe to use if you know what the specific problem is and you are sure that that problem does not matter for your present purposes. Clearly we are not in that situation here, at least not yet.

            It is interesting that when you switch the reference category, the not estimable category also switches. I have to say I cannot think of why that should happen. It would also be helpful to know if you get the same phenomenon when you use -xtreg, fe- instead of -reghdfe-.

            I have tried to conjure an example of this happening on my setup using available data sets, and, so far, I have not been able to contrive to make it happen . Either I get everything not estimable, or in other circumstances, everything is estimable. So I think it would be helpful if you posted back with example data, showing an example that reproduces the problem when run with the code you show. Please use the -dataex- command* to do that.

            *If you are running version 18, 17, 16 or a fully updated version 15.1 or 14.2, -dataex- is already part of your official Stata installation. If not, run -ssc install dataex- to get it. Either way, run -help dataex- to read the simple instructions for using it. -dataex- will save you time; it is easier and quicker than typing out tables. It includes complete information about aspects of the data that are often critical to answering your question but cannot be seen from tabular displays or screenshots. It also makes it possible for those who want to help you to create a faithful representation of your example to try out their code, which in turn makes it more likely that their answer will actually work in your data.

            Comment

            Working...
            X