You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the most precise approach, but larger margins can have some advantages:
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)
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.
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.
The text was updated successfully, but these errors were encountered:
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
mtr()
currently adds one cent to income to determine marginal tax rates, with an argnegative_finite_diff=False
to make that negative one cent instead:Tax-Calculator/taxcalc/calculator.py
Lines 542 to 546 in 1688c12
This is the most precise approach, but larger margins can have some advantages:
Some precedent:
I'd suggest adding an arg defaulting to 0.01, named something like
finite_diff
,margin
, ormarginal_amount
. Over time this could also potentially replace the existingnegative_finite_diff
arg.The text was updated successfully, but these errors were encountered: