Open PavelMakarchuk opened 1 year ago
@nikhilwoodruff Just want to confirm that this doesn't appear to be driven by my recent changes on API #230?
Unfortunately, I probably wouldn't have time on this this week, perhaps also not next, but I'll try to find some time.
It seems to come up every time I reload a saved household
Could this have anything to do with PR #3021? I realize it wasn't fully committed, but thought there might be some overlap
@anth-volk said in issue #3071:
Could this have anything to do with [issue] #3021 [that generated PR #3036]? I realize it wasn't fully committed, but thought there might be some overlap.
I think it is plausible to think there is "some overlap." However, PR #3036 has not even been reviewed much less committed.
I just hit this bug, could it also be related?
@MaxGhenis, So you mean in issue #3071 that the household_net_income
on the Y-axis is tiny in comparison to the level of employment_income
for the household head on the X-axis?
I have no idea what is going on in the webapp, but the two related issues I have submitted --- issue #3017 and issue #3029 --- show clearly that there are problems with the calculation of marginal tax rates and cliff gaps in the PolicyEngine-US source code.
Why don't you answer your own question by creating a new PolicyEngine-US test (using the case in your webapp example) to see if the test gives the expected values for household_net_income
. If so, then the problem is probably in the webapp.
Just did some testing - I think this issue must have something to do with the PE-US package and not the web app. The key is that, for some reason, household #34494, which has no household income, receives a household_net_income of 0 when simulated under US default policy. One I just created, #34553, also has no net income, but when placed under US default policy, it's simulated to have a net income of around $20,500.
If you notice, too, #34494 has no default "Net income" option in the variable dropdown menu, perhaps because the output 0 is falsy? I'm sure this then also ruins the calculation of "Market income."
I even tested it all by manually inputting all the household variable definitions that #34494 has - single, 1 child, Colorado, no income for anyone, ages 40 & 5, and received a working output, though I didn't add any reform policy, as it didn't seem like that was included in #34494.
So my thoughts are something like this. I think it's possible that either there was a change to Colorado calculation specifically that somehow breaks this (though that seems unlikely), or there is some particular variable that was input when #34494 was created that broke this (would be helpful to know if some alternative value was input). Otherwise I'm at a bit of a loss, but it doesn't appear to be a front-end or API thing.
@anth-volk said:
Just did some testing - I think this issue [#3071] must have something to do with the PE-US package and not the web app.
Can you share with us the YAML test file(s) you wrote to test PolicyEngine-US?
@martinholmer I don't think this is related to the issues/PRs you've filed since they only occur in rare occasions in the web app, and in the cases I've looked at the results from the Python package seem fine. Your changes seem like they would affect a much wider range of households (all except California right?).
@martinholmer To be clear, I didn’t write any unit tests, only used browser debugging and manual inspection of API returns
On Sep 27, 2023, at 9:49 AM, Max Ghenis @.***> wrote:
@martinholmer https://github.com/martinholmer I don't think this is related to the issues/PRs you've filed since they only occur in rare occasions in the web app, and in the cases I've looked at the results from the Python package seem fine. Your changes seem like they would affect a much wider range of households (all except California right?).
— Reply to this email directly, view it on GitHub https://github.com/PolicyEngine/policyengine-us/issues/3071#issuecomment-1737663711, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADSK7W3WYHNI5C4W3F4YUE3X4RDJZANCNFSM6AAAAAA5CIB7KQ. You are receiving this because you were mentioned.
In the following scenario the MTR does not seem to be computed.
In some instances it seems to be not computed in combination with a reform.
It seems to occur sporadically as the same household compositions have sometimes returned and sometimes not returned MTRs.
@nikhilwoodruff @anth-volk