feenberg
commented
4 years ago The tax calculator should not require E00100. Think about it. If you want to calculate the revenue from a change in the definition of AGI, then if the calculator uses E00100 from the data instead of the the calculated AGI, it will get the wrong answer. This should be fixed in the calculator.
Now, if the E00100 is only used as a tab variable in the display, my argument is only a little weaker. I wonder if E00100 influences the tax calculation at all in the current code. If it did, wouldn't it have come to light as an error in some score? Maybe it is on a list of required variables, but doesn't actually influence the calculation.
Dan
On Tue, 5 Nov 2019, Don Boyd wrote:
Of interest to at least the following: @andersonfrailey, @MattHJensen, @martinholmer, @MaxGhenis, @feenberg, @marshallpku, and @gchen3
Despite well-laid plans, we have run into a significant problem running a synthetic version of the PUF through TaxData.
I think there is a short-term solution that will not require changes to TaxData and eventually could be incorporated into synthesis procedures.
My questions are: Will my proposed solution work? Is there a better short-term solution? Is there someone willing to assist in the short-term solution? @feenberg, if my workaround number 1 works, I would much appreciate your help.
Here is the problem: TaxData requires E00100. We have not synthesized E00100 and even if we did it would be wrong because it is a complex calculation based upon other variables we synthesize. It has to be calculated from those variables after they are synthesized.
This creates a circular problem:
- We want to run the PUF-format synthetic PUF through TaxData so that it can be used in Tax-Calculator.
- To do that, we need E00100.
- But we cannot synthesize E00100, we must calculate it.
- Tax-Calculator can construct the calculated counterpart to E00100, c00100 (albeit not for the desired year of 2011, but for a close substitute, 2013).
- But Tax-Calculator won't do this with a PUF-format file. It needs a file with certain of the enhancements ordinarily done by TaxData, particularly prime-spouse splitting of E00200, E00900, and E02100.
- (Perhaps Tax-Calculator requires other enhancements made by TaxData but I don't know that.)
Workaround number 1:
- @feenberg would it be possible to run the synthetic no-disclosures PUF through taxsim and get AGI that way? If so we would just name it E00100, add it to the synthetic PUF file, and call it a day (for now).
- I really hope this is the solution.
If not, then ... workaround number 2:
- It is important to VERIFY: Why do we need E00100 in TaxData if Tax-Calculator will calculate its own version, c00100? Answering this will tell us something about how faithful the AGI calculation needs to be to AGI that IRS would have calculated if it had constructed the synthetic PUF. I think E00100 is probably used in TaxData to help ensure that other values make sense - for example it probably is used in statistical matching against the CPS, or in determining benefit amounts, or in the targets used for reweighting. If these are the uses of E00100, then perhaps a calculation that is 95% or 98% faithful to the actual 2011 calculation (2011 is the year of our PUF) will be adequate.
- @andersonfrailey can you elaborate on the important uses of E00100 in TaxData?
- If my suspicion above is correct that E00100 is used for the reasons I gave, then with someone else's help, we might write a slimmed-down version of an AGI-calculation function -- or even pseudocode -- that relies only on variables found in the PUF. I assume this would be a version of AGI in calcfunctions.py in Tax-Calculator.
- It would be specific to 2011, ideally but if need be I think in the short term it could be based on 2013. (I believe - subject to refutation by people who have looked more closely - that the changes in AGI definition between 2011 and 2013 were extremely minor.) Please keep in mind that our purpose here is testing a fully TaxData-enhanced synthetic PUF within Tax-Calculator and we need some sort of workaround to get us there. That means we can be imperfect now. This is not our first shot at it: we will eventually be synthesizing improved synthetic PUFs and as we do that we can improve our approach to this issue.
- The problem for me is that the AGI calculation in Tax-Calculator relies on interim calculations that would take me a long time to understand. Much better if someone else could say here's how we would do it with PUF-only variables, just for 2011 (or 2013).
- I would then write and run this function in R (or python), pre-processing the synthetic PUF to create an acceptable E00100 before it is fed into TaxData.
I have a third suggested workaround if neither of these works but it is more work, and more complex, and would entail changes to a version of TaxData; first I think it would be good to get some reaction to these ideas.
Thoughts, anyone on how best to proceed?
[Aside: If you are wondering how I previously tested our synthetic PUF in Tax-Calculator without running it fully through TaxData and addressing this issue, here's what I did then. I created 50/50 splits of the prime-spouse variables on all married records, for both the true PUF and the synthetic PUF, which created a file that could go through Tax-Calculator and allowed apples-to-apples comparisons of PUF and synthetic PUF. That was fine for that purpose and the current issue did not arise as we did not need E00100. But now we want a full TaxData enhanced PUF, with realistic estimates of prime-spouse splits and with other TaxData enhancements so we have to address this issue.]
? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, orunsubscribe.[AB55AVLHZPRSSKG7KCV6D73QSFVEPA5CNFSM4JJCI7A2YY3PNVWWK3TUL52HS4 DFUVEXG43VMWVGG33NNVSW45C7NFSM4HW4MBBA.gif]
donboyd5
Of interest to at least the following: @andersonfrailey, @MattHJensen, @martinholmer, @MaxGhenis, @feenberg, @marshallpku, and @gchen3
Despite well-laid plans, we have run into a significant problem running a synthetic version of the PUF through TaxData.
I think there is a short-term solution that will not require changes to TaxData and eventually could be incorporated into synthesis procedures.
My questions are: Will my proposed solution work? Is there a better short-term solution? Is there someone willing to assist in the short-term solution? @feenberg, if my workaround number 1 works, I would much appreciate your help.
Here is the problem: TaxData requires E00100. We have not synthesized E00100 and even if we did it would be wrong because it is a complex calculation based upon other variables we synthesize. It has to be calculated from those variables after they are synthesized.
This creates a circular problem:
Workaround number 1:
If not, then ... workaround number 2:
I have a third suggested workaround if neither of these works but it is more work, and more complex, and would entail changes to a version of TaxData; first I think it would be good to get some reaction to these ideas.
Thoughts, anyone on how best to proceed?
[Aside: If you are wondering how I previously tested our synthetic PUF in Tax-Calculator without running it fully through TaxData and addressing this issue, here's what I did then. I created 50/50 splits of the prime-spouse variables on all married records, for both the true PUF and the synthetic PUF, which created a file that could go through Tax-Calculator and allowed apples-to-apples comparisons of PUF and synthetic PUF. That was fine for that purpose and the current issue did not arise as we did not need E00100. But now we want a full TaxData enhanced PUF, with realistic estimates of prime-spouse splits and with other TaxData enhancements so we have to address this issue.]