-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when calculating n2164 intermediate variable using PUF #2469
Comments
Ah turns out I identified this in June 2019: PSLmodels/taxdata#318 Since #2463 is backwards-incompatible, I'd prefer to drop the |
@MaxGhenis, we could do a phased deprecation: in a minor release, add n2164, n65, and a warning that n21 is being removed in the next major release, please use the other two instead. I've been thinking we need to add this kind of phased deprecation approach anyways (see, e.g., #2413 (comment)) That said, I'm also open to your suggestion of setting n2164 to zero in the negative cases and proceeding with these changes in 3.0.0 for now. |
Sure, there isn't a rush on this, so reverting #2463 and re-implementing as a phased deprecation sounds good. |
Sounds good, thanks @MaxGhenis. I'll leave this issue open after #2471 reverts #2463. If this becomes urgent before the TaxData patch is ready, I'll be open to setting |
@MaxGhenis's work in #2463 splits
UBI_21
intoUBI_2164
andUBI_65
by calculating an intermediate variablen2164
that counts the number of people in a filing unit between the ages of 21 and 64. Reasonably, he includes this check:assert n2164 >= 0
because a filing unit should not have negative people in it. Unfortunately, that is not the case with the PUF. There are numerous filing units withn2164
values of -1, socalc_all()
fails when using PUF.My guess is that this issue will have to be sorted out in taxdata (cc @andersonfrailey), so it might make sense to revert #2463 until we come up with a solution.
cc @MattHJensen
The text was updated successfully, but these errors were encountered: