search

JMSLab / eventstudyr

Other
24 stars 1 forks source link

Enable estimation using -fixest- #42

Open jorpppp opened 1 year ago

jorpppp commented 1 year ago

For some of our work we would like to estimate models with large numbers of fixed effects. Currently eventstudyr uses plmunder the hood, but it would be useful to be able to use fixest too.

jorpppp commented 1 year ago

I am tagging my coauthor @reginalpzley here since she noticed this issue. She may be able to help us add this enhancement in the future.

zhizhongpu commented 3 months ago

@jmshapir Hi I might be able to start working on this this week. Please assign me and allow me to open an issue branch.

jmshapir commented 3 months ago

@zhizhongpu thanks! Permissions elevated. Please use it wisely.

@santiagohermo if you think you may have some time to pitch in here (or even just to help @zhizhongpu get familiar with the package), please reach out to me via e-mail and I will put you in touch.

santiagohermo commented 3 months ago

Thanks @jmshapir!

Absolutely, happy to discuss the package and the fixest implementation with @zhizhongpu. I'll get in touch via email.

zhizhongpu commented 2 months ago

per meeting w/ @santiagohermo

Given that fixest is quite different from the current kernel i.e. estimatr, the next step is to add an argument to EventStudy(), default being TRUE, where the user can specify whether to use the default kernel fixest (or instead use estimatr). This means we'll keep the current code as legacy/superseded to be deprecated. The alternative is to remove the estimatr-based code in this issue.

We also discussed another issue. Since @santiagohermo prefers that we make different modifications in separate issues, I've opened #51. I'll start working on #51 first as it's smaller and can get me more familiar with the package.

fyi @jmshapir please flag if this plan does not sound good to you.

santiagohermo commented 2 months ago

Thanks @zhizhongpu! A pleasure to meet you, and happy to talk again in the future if helpful :)

I'm thinking that it might be wise to keep both options for a couple of reasons:

We probably don't need to decide right now. We can always just add the fixest implementation and decide whether to deprecate (or not) the estimatr one later.