Case where constant is not absorbed by the fixed effects.

[sergiocorreia]

Case where constant is not absorbed by the fixed effects.

[sergiocorreia]

In a way the absorb() variables take the place of the constant. On previous versions of -reghdfe- I was forcing the first absvar to be just categorical variables (no c.x) but that was because of design limitations.

One option may be to remove the -nocons- in those cases, but not sure if it's worth the coding effort (I need to modify the ivregress/ivreg2/regress/mwc wrappers).

Another would be to automatically add a constant as the first absvar.

All in all, I'm not sure. Specially because pure i.id#c.year interactions converge extremely slow in my experience. For instance, if you replace # by ## you will see that it converges in e.g. 6 iterations instead of 80.

[matthieugomez]

It's definitely not worth the coding effort. It's really a unusual case - but I was misled by the result, so it seems like something should change. Catching this case to return an error, asking the user to create a cons variable sounds good. It's fairly easy to understand what happens since you don't report the cons anymore.
Just for info, you don't think reghdfe is better than reg in this case?

[sergiocorreia]

Makes sense, I'll just give a warning if no "fixed-intercepts" are found in absvar.

About regress vs reghdfe... the simple benchmarks I run were for fixed intercepts not fixed slopes, so I'm not sure (if you have better names to distinguish i.var from i.var##c.var let me know).

If there are only a few individuals sure regress is faster, but with 1000 or so individuals then it's likely the opposite. If you have ##c. interactions instead of #c. interactions, then reghdfe is definitely faster. If you have cluster errors then even more (which makes me wonder.. as I didn't do any optimization regarding clustered errors, so regress/areg probably had some gross inefficiencies there)

[matthieugomez]

Related issue in hdfe: when I use a(var1#c.var2), I get an error telling me to add constant (exactly the kind of error reghdfe could throw). If I do it, I get the error "idvar not found". Workaround is to add cluster(var1) so not a problem for me.

[sergiocorreia]

Since hdfe is still at version 2, that behavior is expected.

What I couldn't replicate is the "idvar not found" error:

. hdfe, version
2.1.10 07apr2015

. sysuse auto
(1978 Automobile Data)

. hdfe price weight , a(turn#c.gear) gen(A_) // This fails
error parsing absorb : first absvar cannot be continuous interaction
solution: i) reorder absvars, ii) replace # with ##, iii) add a constant as first absvar (as a workaround)

. gen const = 1

. hdfe price weight , a(const turn#c.gear) gen(A_) // This works

[matthieugomez]

I can't replicate it either, not sure what happened. Sorry.

[matthieugomez]

Allrigh I got it!

reghdfe, version
*2.1.47 12may2015
 sysuse auto, clear
gen cons = 1
reghdfe price weight , a(cons turn#c.gear turn#c.trunk)

It's actually a bug unrelated to my initial report. the following also fails:

 sysuse auto, clear
reghdfe price weight , a(turn turn#c.gear)

Also note that in the reghdfe price weight , a(turn turn#c.(gear trunk)) returns an error ") required"

[sergiocorreia]

Matthieu,

Since this is an unexpected behavior, would it be enough if I gave a warning in case absorb() only contains fixed slopes? Maybe also allow _cons as a magic variable in absorb(), but that may just complicate things too much.

[matthieugomez]

Of course, this is great