Refactor income tax code to make object-oriented

[bblockwood]

The goal of this issue is to refactor our existing optimal income tax simulation code in /projects/optimal_tax_simulations/simplified_optimal_income_tax_simulation/ to take advantage of object oriented organization.

Please look to the simulations in the lottery project (see here) for an example of how how I'd like to implement this.

Note to @afras-sial: no rush on this — it is a "back burner" item.

[afras-sial]

@bblockwood I returned this to task while I had some downtime and added an oo_version branch. I've implemented this with the RobustTaxes standards for convergence, but with exogenous MSWWs (so there are subclasses with weaker and stronger redistributive preferences). As is the case with the RobustTaxes simulation, we need to make some decisions about smoothing. In particular, the original version (not object-oriented) used a moving average smoother directly on the MTR proposal twice to produce:

Similarly applying two players of moving averaging smoothing to the MTR proposal (on top of the Lowess smoothing we apply as we do in the RobustTaxes simulation), we now get:

Other variations include no smoothing to the MTR proposal but very heavy smoothing of the empirical income and consumption distributions, producing:

and just one layer of Lowess smoothing to the MTR proposal (this is currently committed version), producing:

[bblockwood]

@afras-sial thanks for circling back to this, I agree this is a worthwhile thing to invest in. It is reassuring that these different smoothing strategies give largely consistent results. However I note that in plots 3 and 4 above, the top tax rate does not plateau, but instead appears to decline again as incomes rise. (That's especially pronounced in 3.) That is something we would like to avoid, as we know that with a Pareto income tail, the MTR should approach an asymptote from below, but not start to decline again. (This seems like a worthwhile thing to understand, as it might be related to why we're seeing the nonmonotonicity across high incomes in the RobustTaxes simulations.)

I confess I don't really understand why we see the nonmonotonicity in 3 is so much more pronounced than in the others — maybe something about the heavy smoothing procedure makes the underlying income distribution have a thinner-than-Pareto top tail? Could we check this by plotting the local Pareto parameter (or the zBar/z_m parameter) in the case with and without the heavy smoothing to see if the former appears less stable?

[afras-sial]

@bblockwood Yes, the non-monotonicity from 3 comes from the smoothing of the underlying income distribution, so the lack of asymptoting of rates at the top is not really unexpected. The more smoothing applied to the income distribution, the more steeply the local zBar/z_m parameter decreases with income. The moving average smoother dampens this effect (edit: more so than Lowess smoothing), which is why those rates seem to asymptote most cleanly.

[bblockwood]

See comment here.

[afras-sial]

@bblockwood With a smaller step size and without needing to smooth the empirical income or consumption distributions or the raw MTR proposal or its denominator, we are able to achieve convergence in this simulation with a synthetic upper tail on the income distribution (and a consumption distribution interpolated to match).

Here is the local zBar/z parameter chart:

And here are the MTR schedules:

I am still working on adapting a similar strategy to the more complex simulations.

[bblockwood]

Excellent, these look very nice — if this can be adapted to the uncertain specifications, that will be a huge win. Thanks for working at this!

[bblockwood]

Incidentally, I think we can pick up the conversation about the uncertain specifications in the RobustTaxes repository issues. If you are comfortable with where the code stands in this baseline case, please commit to master and close this issue.

[afras-sial]

There is one part of creating the upper tail on the income distribution that requires me to manually rescale the last income cell before filling in all of the other income cells, which I will try to automate if possible. I'll keep this open until I can look further into that.

[afras-sial]

@bblockwood I was able to automate the creation of the income distribution and have merged the oo-version branch into master.

[bblockwood]

@afras-sial I had one further request here, based on some thinking about the RobustTaxes appendix:

Could you create a figure like this one from your post above, which adds to the plot the zBar/z ratio for the original distribution (without the synthetic Pareto tail) as well?

The motivation is that I noticed this footnote in the RobustTaxes appendix:

and I wanted to check that the 90th percentile is sufficiently high that the local Pareto parameter there is approximately equal to the asymptotic parameter.

Thanks!

[afras-sial]

@bblockwood Please see the requested plot below:

I originally set the Pareto tail to start above $150k in income, but after reading the MWY appendix, I changed it to be percentile-based, lowering the starting point by a few cells. Here are the tax rates with the tail starting above the 90th percentile income:

[bblockwood]

Great thanks @afras-sial. One more trick is to impose smooth pasting for the transition to the Pareto tail, where we gradually transition over the course of say 5 or 10 cells, with weights rising progressively from 0% to 100% on the Pareto tail. Can you try that to see if that gets rid of the bump at 125K?

[afras-sial]

@bblockwood I tested this out in a few different ways (either by weighting the incomes directly or by weighting the target parameter I used to generate the incomes for the new tail across different cell ranges) and it didn't eliminate the bump. In some cases, it just stretched out the bump, while in others it prevented convergence.

[afras-sial]

@bblockwood I was able to mostly get rid of the bump by replacing the first three cells of the Pareto tail with weighted averages of the Pareto tail incomes and the status quo income corresponding to those cells (I wasn't applying the right weights to the right range of cells before). Please see the resulting tax schedules below:

Edit: I also added a line of code to check that incomes are non-decreasing in wage at the optimum.

[bblockwood]

Fantastic — thanks @afras-sial! Closing this issue.

[afras-sial]

Reopening this as a reminder to rescale consumption so national income and consumption are equal in the status quo and the exogenous revenue requirement is 0.

[afras-sial]

Closing this issue since I've now rescaled consumption so national income and consumption are equal in the status quo and the exogenous revenue requirement is 0 (which has no material effect on tax rates at the optimum).