search

bblockwood / lab

Repository for collecting and documenting work done by research assistants.
0 stars 0 forks source link

Create simplified optimal income tax simulation #6

Closed afras-sial closed 4 years ago

afras-sial commented 5 years ago

Simplify the optimal tax simulation code to omit SSB consumption subutility and the commodity tax. Essentially create an updated version of the Mankiw-Weinzierl-Yagan optimal income tax simulation. @bblockwood

afras-sial commented 5 years ago

@bblockwood Do you have any resource that could help me in understanding how to adapt the income effect on labor supply, eta_z , and the compensated earnings response to a marginal tax rate perturbation, dzdT, to the case without SSB subutility?

The code for eta_z: https://github.com/bblockwood/lab/blob/53e99f4a30f6982efcc69264e85b48d8e490bfd7/projects/optimal_tax_simulations/simplified_optimal_income_tax_simulation/code/functions/compute_inc_effect_labor_supply.m#L5-L8

The code for dz/dT:

https://github.com/bblockwood/lab/blob/53e99f4a30f6982efcc69264e85b48d8e490bfd7/projects/optimal_tax_simulations/simplified_optimal_income_tax_simulation/code/functions/compute_labor_supply_response.m#L4-L7

The code for SOC_z:

https://github.com/bblockwood/lab/blob/53e99f4a30f6982efcc69264e85b48d8e490bfd7/projects/optimal_tax_simulations/simplified_optimal_income_tax_simulation/code/functions/compute_SOC_labor_supply.m#L5-L11

I see that in Saez (2001), eta_z is defined as: Capture3, with R = consump - income*(1 - T') and that in the paper, eta_z is defined pretty similarly as: Capture4, but I'm not entirely sure how to get dz_hat/dnu | nu = 0.

bblockwood commented 5 years ago

Good question. It's actually super simple in this case — our utility function without SSBs is just

image

which has no income effects on labor supply, so eta_z in going to be zero. We can see this by noting that the first-order condition for the optimal choice of z is:

image

Now if we totally differentiate that equation with respect to nu, letting z be a choice variable, we get

image

and since the first term is zero, by the definition of T hat, we get that eta_z = 0.

afras-sial commented 5 years ago

@bblockwood Is the formula for mtr_raw in the appendix? Just trying to see what should happen to the first term with no income effects

https://github.com/bblockwood/lab/blob/53e99f4a30f6982efcc69264e85b48d8e490bfd7/projects/optimal_tax_simulations/simplified_optimal_income_tax_simulation/code/functions/compute_income_tax.m#L15-L17

bblockwood commented 5 years ago

@afras-sial yes, it's equation (38) in the appendix. When there's no SSBs, then there's no dB term, so it's just mtr_raw = -1./(f.*dzdt) .* dM. That corresponds to the following pared-down version of Equation 38:

image

When there are no income effects, ghat is simply equal to g (you can see this in Footnote 15 from the paper).

afras-sial commented 5 years ago

@bblockwood This is what I have so far. I'm not exactly sure why it looks like this, but I'm going to go through the code to see what might be happening.

Capture5
bblockwood commented 5 years ago

Nice! This is looking reasonable in a lot of ways. Do the rates become negative at the very bottom, or just bottom out at zero?

For now, let's leave these simulations as is, they seem quite good, and just work on cleaning up whatever other code and deleting files as necessary so that the code is clean. Thanks for your great work on this — you've gotten up to speed much faster than I even hoped.

afras-sial commented 5 years ago

@bblockwood The rates do become negative at the very bottom, at around -.1 for the lowest income group.

bblockwood commented 5 years ago

Thanks for checking. I suspect that is from a numerical issue then, as the analytic expression for the optimal tax expression should never be negative. Can you explore to see which component of the MTR formula is flipping signs at the bottom? I suspect it's dM. That term should be zero at the bottom and become immediately positive at z>0.

afras-sial commented 5 years ago

Yes, I checked and dM was negative at the bottom.

bblockwood commented 5 years ago

As discussed on Slack, @afras-sial will explore refactoring this codebase to compute specifications using object oriented programming rather than switches.

afras-sial commented 5 years ago

@bblockwood Sorry it took so long, but I just finished refactoring the codebase to eliminate the switches. It's not necessarily more elegant or clear, but I see how it could help in a codebase with a lot more switches.

bblockwood commented 5 years ago

Cool, thanks — I see what you have done. It's great to see this syntax, and I have some thoughts on how it can be refined to be simpler — but I think it will be easiest for me to take a shot at that sometime soon. For now, can you switch back to the "master" branch and use that codebase to move forward with the tasks in the RobustTaxes project?

afras-sial commented 5 years ago

Yes, sounds good.

bblockwood commented 4 years ago

Closing issue.

Summary: