CBOupdate

[lmm8ka]

updating CBO and IRS values using 2018 data, projecting 2028

[andersonfrailey]

Thanks for working on this, @lmm8ka. Initial code review looks good. I'm going to run Tax-Calculator with the new weights and growth rates to see how the results are affected.

In the meantime, can you also update the CBO baseline updating instructions? We just need the year of the sources updates to match this update.

[andersonfrailey]

Ran the new weights, ratios, etc. through Tax-Calculator and the results are nearly identical. I did have some trouble using the new PUF ratios in Tax-Calc, but I was able to work around it. I'd be curious to see if anyone has any insight into what caused the issues. You can see the notebook I did the work in here.

cc @martinholmer

[andersonfrailey]

If there are no comments on this, I'll merge on Tuesday.

cc @martinholmer @lmm8ka

[martinholmer]

@andersonfrailey, Welcome back from New Delhi. Can you leave PR #289 open a little longer?
I've have some time this week to look into it.

@lmm8ka

[martinholmer]

@andersonfrailey, I see you've already merged PR #289.

[andersonfrailey]

Sorry, @martinholmer. I can revert the merge if need be.

[martinholmer]

@andersonfrailey said:

I did have some trouble using the new PUF ratios in Tax-Calc, but I was able to work around it. I'd be curious to see if anyone has any insight into what caused the issues.

Can you explain what you mean by this statement?

No need to revert the merge of PR #289.

[andersonfrailey]

@martinholmer, when I passed the path to the new ratios as an argument to to the Records class, the file was read, but the 2028 values were missing. The new values up to 2027 were there so it appears that the correct file was being read, but the 2028 values were just being dropped.

I know this wasn't a problem with the file path or the file itself because when I read it with Pandas all of the years including 2028 were there.

[martinholmer]

@andersonfrailey said:

when I passed the path to the new ratios as an argument to to the Records class [constructor], the file was read, but the 2028 values were missing. The new values up to 2027 were there so it appears that the correct file was being read, but the 2028 values were just being dropped.

But the values for 2017 and before are not any different in PR #289 than they were before #289.
So, I'm confused by this part of your statement.

If the 2018 values were not there, then it would appear that you've run across a bug in the Tax-Calculator Records class logic. Since nobody else has run across this bug, can you file a bug report in Tax-Calculator? Be sure to include a (hopefully simple) script that reproduces the bug. I can't fix anything that I can't see. Thanks.

[andersonfrailey]

@martinholmer I'll try and recreate the problem I was running into and will open up a corresponding PR with that information.

[martinholmer]

@andersonfrailey, I'm still a little puzzled about why the new growfactors.csv file generated in PR #289 has exactly the same growfactor values as before #289 for every year up through 2027. Only the newly added 2028 values are different than before #289.

Did CBO not change its CPI inflation (for example) projection for the years 2019-2027?

[andersonfrailey]

@lmm8ka would be in a better position to answer that, @martinholmer. Though this may have been a failure in communication on my part. @lmm8ka, when you were updating the numbers did you replace the old numbers with the new projections or just add the 2028 projections to the end of the rows?

[lmm8ka]

@andersonfrailey @martinholmer on this one I did only update for 2028; I didn't realize the projections may have changed for the future years that were already projected, although intuitively I should have realized that beforehand.

[martinholmer]

@lmm8ka said in merged pull request #289:

@andersonfrailey @martinholmer on this one I did only update for 2028; I didn't realize the projections may have changed for the future years that were already projected, although intuitively I should have realized that beforehand.

Given the seriously incomplete nature of PR #289, it seems like #289 should be reverted because currently the master branch is wrong.

[andersonfrailey]

@martinholmer, @lmm8ka is working on resolving this issue right now. She should have a second PR open tomorrow so I think it would be easier to review and merge that PR quickly than revert and start totally from scratch.

[martinholmer]

@andersonfrailey said:

@lmm8ka is working on resolving this issue right now. She should have a second PR open tomorrow so I think it would be easier to review and merge that PR quickly than revert and start totally from scratch.

OK. If she's working that fast, then you're right to think it will be easier to leave the incomplete CBO update as part of the master branch.