Custom margin for mtr function

[MaxGhenis]

mtr() currently adds one cent to income to determine marginal tax rates, with an arg negative_finite_diff=False to make that negative one cent instead:

Tax-Calculator/taxcalc/calculator.py

Lines 542 to 546 in 1688c12

	def mtr(self, variable_str='e00200p',
	negative_finite_diff=False,
	zero_out_calculated_vars=False,
	calc_all_already_called=False,
	wrt_full_compensation=True):

This is the most precise approach, but larger margins can have some advantages:

1. Actual marginal labor supply decisions occur on margins larger than one cent (e.g. a raise or adding an hour per week; the range of likely margins could potentially be empirically determined)
2. Tiny margins can miss discontinuities if not present in the microdata; for example, suppose a tax provision produced a cliff where going from $40,000 to $40,001 income raised tax liabilities by $1,000. If nobody in the microdata has income of exactly $40,000, this will show up as having no effect on labor supply, even though it would affect decisionmaking of people around the ~$39,000 to $41,000 income range deciding whether to cross that threshold.
3. Smoother MTR curves can work better with general equilibrium models like OG-USA.

Some precedent:

• @nikhilwoodruff has found that UK analyses sometimes consider the "participation tax rate" in addition to MTRs, which add a larger amount to earnings for people currently with zero earnings
• @jpycroft mentioned that the EC has added a percentage to income (IIRC 0.5% or 3%) when calculating MTRs

I'd suggest adding an arg defaulting to 0.01, named something like finite_diff, margin, or marginal_amount. Over time this could also potentially replace the existing negative_finite_diff arg.

[nikhilwoodruff]

(This is one paper that uses it, by the IFS; see pages 11 and 12 for the different metrics they have for work incentives - EMTR, PTR and RR.)

[feenberg]

On Tue, 30 Mar 2021, Max Ghenis wrote: mtr() currently adds one cent to income to determine marginal tax rates, with an arg negative_finite_diff=False to make that negative one cent instead.

This is a question I have wrestled with for decades in taxsim. For a table of the weighted average marginal tax rate, notches are not a problem. A few will be encountered, and affect the averge to a suitable extent. The problem is with notch mtrs in regressions. In an OLS regression minimizing squared residuals an outlier will have disproportionate influence. A dingle wild mtr will dominate the sum of squares. The usual suggestion for dealing with notches is to take a longer finite difference. If there is a $10 notch than taking a finite difference over $1 yields a 1,000% marginal tax rate, but over $1,000 it only adds 1% to the mtr. However notches of several hundred dollars are in the law, and minimizing them requires very large finite differences. Eventually I settled on minimizing the probability of encountering a notch, and suggesting to users that they drop observations with absurd mtrs. If you take a finite difference of a penny, then even a $1 notch is a 10,000% mtr. I also start out each mtr calculation from their reported wage income plus a penny compared to plus 2 pennies. Since most notches seem to ocurr at integer dollar thresholds, this works well. Lastly, I compare the finite difference in both directions, and use the small (absolute value) amount. The result is a very small bias Nevertheless, notches should not be problem for distribution tables. Daniel Feenberg