Add PDF "readme" to describe what this simulation does.

[bblockwood]

Modeled on the style of the appendix to RobustTaxes. No rush on this, but it will be a useful addition to this code base for teaching purposes.

[afras-sial]

@bblockwood Why don't we use the labor supply fixed-point algorithm to update income in each loop in this simulation?

Is it because the computed income from the RHS of the FOC is presumably not "too far" off from the fixed point in each loop? And when we near convergence in the optimal tax loop, updates to the tax schedule and consequently income become quite small, so the income on the LHS side and the income inputted to find the relevant MTR on the RHS are approximately equal so the FOC approximately holds?

When I tested out adding the optimal labor supply loop to this simulation, it ran much slower but the resulting tax schedules looked identical.

[bblockwood]

Thanks @afras-sial. If I understand what you're asking, I think the answer lies in the difference between the tax instrument in this simulation vs. in RobustTaxes. Here, we're technically choosing a marginal tax rate to apply to each skill level, which remains the same (for them) regardless of how much they earn. As a result, since there are no income effects, there's no fixed point to find for labor supply — once you know the (updated) marginal tax rate for a particular type, you can explicitly compute their new optimal labor supply in closed form. In the end, it will turn out that incomes are increasing in types, so we can then re-characterize that tax-by-type schedule into a tax-by-income schedule, which is what we plot. So in the end, it's identical to computing a tax-by-income schedule, but that would just take much longer.

This tax-by-type approach isn't feasible in RobustTaxes, because a given type will have different levels of income in different states of the world, so there's no isomorphism between a tax-by-income schedule and a tax-by-type schedule. That necessitates including the labor supply fixed point interior loop.

Does that make sense, and does it answer your question? (If not, expound a little more and I'm happy to take another shot.)

[afras-sial]

@bblockwood Ok, I think I understand. So, in this case, we have: since the marginal tax rate is applied to each wage?

[bblockwood]

That looks right. (It’s just the equation used to impute the wage from the income in the status quo, but inverted from w = fn(y) to y = fn(w), right?)

[afras-sial]

Yes, that and now T' is directly a function of w.

[bblockwood]

Right. Sounds good.

On Sep 10, 2020, at 10:36 AM, Afras Sial notifications@github.com wrote:

Yes, that and now T' is directly a function of w.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bblockwood/lab/issues/8#issuecomment-690331690, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHJQROMDZOEZTKUQNBD3VLSFDP5VANCNFSM4P74FKJQ.

[afras-sial]

@bblockwood I decided to work on addressing this very old issue yesterday when I had some time. Can you please take a look at ReadMe.pdf when you have a chance and let me know if I should make any edits?

I didn't completely follow the procedure in the code for obtaining the implicit weights from the status quo US tax system using the inverse optimum approach (in economy_invOpt.m), so it might be helpful if you could explain that a bit further or we could discuss it briefly.

[bblockwood]

Thank you @afras-sial!

Consider this issue closed. I may come back and add some detail to the inverse optimum procedure, but this is perfectly sufficient for now. Thanks!