Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the meaning of fe in "ivcrc y (x=z), fe"? (no explanation in the help document) #2

Open
AlanLee1017 opened this issue Sep 28, 2022 · 8 comments

Comments

@AlanLee1017
Copy link

Hi,
I am trying to run this program with fixed effects dummies using the i.identifier notation, and I can achieve it by adding "xi:" before the ivcrc comand. Luckily, I also found that ivcrc can be followed by a "fe" after the comma, like this "ivcrc y (x=z), fe", but there is no explanation in the help document . So, does the "fe" represent the fixed effect?
Best
Alan

@a-torgovitsky
Copy link
Owner

What type of specification are you trying to run?
Is this a panel with individual fixed effects?

@AlanLee1017
Copy link
Author

What type of specification are you trying to run? Is this a panel with individual fixed effects?

Yes, a panel with individual fixed effects

@a-torgovitsky
Copy link
Owner

a-torgovitsky commented Sep 28, 2022

Can you describe the specification you want to run?

(Meaning what are the variables, what's endogenous, what's time-varying, what's the instrument, etc.)

@d-benson
Copy link
Collaborator

Unfortunately, "fe" is not an undocumented ivcrc option, so running

ivcrc y (x = z), fe

does not do anything with fixed effects. The module ignores "fe" and proceeds on the part it does understand: "ivcrc y (x =z)." The module does not automatically create dummy variables for fixed effects categories (factor variables more generally) or conduct within transformations the way commands like these

areg y x, absorb(id)

or

xtreg y x, fe

would work. However, stata's "xi: ..." wrapper is very flexible and can create temporary dummy variables from categorical data or IDs for most commands, including ivcrc. Other than using "xi: ...", you could manually generate dummies for each fixed effects category, or possibly use stata's within-transformation command "xtdata, fe" if demeaning makes econometric sense given the application.

@a-torgovitsky
Copy link
Owner

The econometric issue here is the first stage quantile regression, which you cannot apply the within transformation to, and which will be subject to the incidental parameters problem.
However, it's possible you could justify the assumptions on an outcome model that has already been within-transformed.
Depends a bit on the specifics.

@AlanLee1017
Copy link
Author

Meaning what are the variables, what's endogenous, what's time-varying, what's the instrument, etc
It's actually an unbalanced panel (5 periods, on average, 5000 individuals/periods)
the specification is as following:
Y_{ict}: the dependent variable ( i-individual, c-county, t-time)
X_{c,t}: the independent variable
Z_{c,t}: the instrument
H_{ict}: the time-varying control variables (including individual\county levels)

@AlanLee1017
Copy link
Author

Unfortunately, "fe" is not an undocumented ivcrc option, so running

ivcrc y (x = z), fe

does not do anything with fixed effects. The module ignores "fe" and proceeds on the part it does understand: "ivcrc y (x =z)." The module does not automatically create dummy variables for fixed effects categories (factor variables more generally) or conduct within transformations the way commands like these

areg y x, absorb(id)

or

xtreg y x, fe

would work. However, stata's "xi: ..." wrapper is very flexible and can create temporary dummy variables from categorical data or IDs for most commands, including ivcrc. Other than using "xi: ...", you could manually generate dummies for each fixed effects category, or possibly use stata's within-transformation command "xtdata, fe" if demeaning makes econometric sense given the application.

Thanks!

@AlanLee1017
Copy link
Author

The econometric issue here is the first stage quantile regression, which you cannot apply the within transformation to, and which will be subject to the incidental parameters problem. However, it's possible you could justify the assumptions on an outcome model that has already been within-transformed. Depends a bit on the specifics.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants