[WIP] itemized deduction surtax and itemized deduction haircut consistency

[MattHJensen]

This PR adds a test to ensure that corresponding itemized deduction haircuts and an itemized deduction surtax produce consistent results per #488.

It also attempts to fix the known inconsistency described in #487 in order to get the test to pass by adding the surtax to _combined as well as to _iitax.

This is a major improvement over current master, but it is still not perfect. Currently _combined under the two scenarios are not almost_equal to two decimals for 0.0732779677577% of records. I am still exploring why these don't match.

[MattHJensen]

I just fixed one issue, which was that BenefitSurtax() in functions.py adjusted ID_casualty_HC when it should have been adjusting ID_Casualty_HC.

This did not entirely resolve our inconsistency between the haircuts and the surtax.

[MattHJensen]

After 982e350 there is now only one record that is inconsistent. In the puf-cps merged file, it is row 125,850 and recid 201,009.

[MattHJensen]

It seems that recid 201,009 is not optimizing their deductions properly. With itemized deductions allowed, the household's combined taxes are 121700.46. Without itemized deductions allowed, their combined tax falls to 121300.94.

cc @GoFroggyRun.

[feenberg]

On Mon, 30 Nov 2015, Matt Jensen wrote:

It seems that recid 201,009 is not optimizing their standard deduction properly. With
itemized deductions allowed, the household's taxes combined taxes are 121700.46.
Without itemized deductions allowed, their combined tax falls to 121300.94.

Without access to the record, I can't be sure what is happening, but this
is possible given that we make the itemization decision without regard to
the AMT. Some taxpayers may do better to take the standard deduction on
the regular tax, but use the itemized deductions on the AMT. It depends on
which deductions they have, and what they are worth on the regular tax. If
a taxxpayer has negative AGI, they may be worthless on the regular tax.

cc @GoFroggyRun.

—
Reply to this email directly or view it on
GitHub.[AHvQVVW6-SX26ttk3sFj0TpsuTL08HQJks5pLGJUgaJpZM4GrDqD.gif]

[GoFroggyRun]

After investigating the unit in the puf file with recid 231150, it turns out that, by merely turning on the haircut for charity contribution, the issue described above that the combined tax falls to 121,300.94 persists. The taxpayer has charity contribution, e19700, of amount 3,270, and is ideally an itemizer beforehand. Note that the charity contribution, e19700, got involved nowhere else in the tax logic except for schedule A, and in the calculation we estimate c19700 using extrapolated e19700.
Switching on the haircut for charity contribution completely doesn't change the fact that the unit would get better off when being an itemizer. But it's puzzling that that unit should obtain lower combined tax amount of 121,300.94.
Given that this is the only problematic one among the whole population, we might want to temporarily rule that unit out while performing the tests before the issue got completely resolved.

cc @MattHJensen

[feenberg]

If you would send me the data and calculated values I can analyze why this
happens, but it doesn't surprise me. Does the taxpayer owe AMT? Can you
set the taxpayer to always itemize? I believe the taxpayer would optimally
itemize but our itemization decision is based on regular tax, not regular
plus AMT. It is possible to make an optimal decision, but costly in
computer time.

dan

On Wed, 2 Dec 2015, Sean.Wang wrote:

After investigating the unit in the puf file with recid 231150, it turns out that, by
merely turning on the haircut for charity contribution, the issue described above that
the combined tax falls to 121,300.94 persists. The taxpayer has charity contribution,
e19700, of amount 3,270, and is ideally an itemizer beforehand. Note that the charity
contribution, e19700, got involved nowhere else in the tax logic except for schedule
A, and in the calculation we estimate c19700 using extrapolated e19700.
Switching on the haircut for charity contribution completely doesn't change the fact
that the unit would get better off when being an itemizer. But it's puzzling that that
unit should obtain lower combined tax amount of 121,300.94. Given that this is the
only problematic one among the whole population, we might want to temporarily rule
that unit out while performing the tests before the issue got completely resolved.

cc @MattHJensen

—
Reply to this email directly or view it on
GitHub.[AHvQVSHWBy7bSGs6Bbq8fI3TpmnKHOEHks5pLzARgaJpZM4GrDqD.gif]

[GoFroggyRun]

@feenberg , thanks for your advice. The thing about current python calculator is that, we are using the costly way to decide whether a unit should itemize or not. More specifically, we compared the income tax before credit amount, c05800, under two different scenario: itemizing or not. And I think this would address part of your concerns.
Regarding more details about this taxpayer: yes, the taxpayer does owe AMT, and is always an itemizer regardless of the charity haircut switch.

[feenberg]

On Wed, 2 Dec 2015, Sean.Wang wrote:

@feenberg , thanks for your advice. The thing about current python calculator is that,
we are using the costly way to decide whether a unit should itemize or not. More
specifically, we compared the income tax before credit amount, c05800, under two
different scenario: itemizing or not. And I think this would address part of your
concerns.
Regarding more details about this taxpayer: yes, the taxpayer does owe AMT, and is
always an itemizer regardless of the charity haircut switch.

Unless it is an issue with credits, then I think there is a problem that
should be investigated. The slow but sure way to solve the problem is to
take a blank tax return and fill it out with the taxpayer data, doing the
calculations along the way and comparing to the computer.

dan

—
Reply to this email directly or view it on
GitHub.[AHvQVYs69UCwsBJpzrEXgaRy2PY8GzPzks5pL7AhgaJpZM4GrDqD.gif]

[MattHJensen]

Closing this in favor of #749. cc @GoFroggyRun and @martinholmer.