Weight and age CPS tax units in the same household together #323
Labels
Comments
MaxGhenis
added a commit
to MaxGhenis/taxdata
that referenced
this issue
Jul 11, 2019
*Not ready to merge* In filing PSLmodels#323 I looked through this file, and took a stab at streamlining the code. Changes include: 1. Using a `wage_bin` function to create wage bins. 2. Using a loop to assign `lhs_vars` dictionary elements.* 3. Using a loop to assign factor variables. 4. Using an `add_target` function to assign `rhs_vars` dictionary elements.* 5. More explicitly adjust `model_vars` for year 2014. 6. Rename `LP` to `lp` since it's not a constant. 7. Other minor changes like comments. \* These pieces won't currently work since they attempt to access `globals()` from within a function (`locals()` also won't work). Per https://stackoverflow.com/q/56983782/1840471, there's no good way to access these, and this is really a sign that something could be done better. It seems to me that sticking with the dictionary elements rather than creating new variables would be a clean alternative. I haven't tested this code yet. Would the right way be to run `make cps-files`?
This was referenced Jul 11, 2019
|
I believe a similar step is discussed at the end of page 142 in this report: https://www.irs.gov/pub/irs-soi/06foertsch.pdf |
|
This report may also be relevant at pg 4: https://www.cbo.gov/system/files/2019-12/55941-CBO-Household-Income.pdf
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Motivation
Andrew Yang's Freedom Dividend is a UBI restricted to adults, plus some tax increases. Since some children file taxes separately from their parents (#321), this causes some tax units to be worse off, since they experience the tax increase without the UBI (analysis). These are low-income tax units, so it makes the plan look overly regressive. This doesn't reflect reality, however, since nearly all share resources with household members that receive the UBI.
Aggregating tax units back to households would address the problem, but this is invalid (PSLmodels/Tax-Calculator#1961), because tax units in the same household have different weights, and they're aged separately.
Others have reaggregated tax units to household or SPM unit and used the original household/SPM unit weight (just adjusting the total tax liability), but this is limited to the most recent CPS tax unit year, and pending the new Python scripts, also relies on separate tax unit creation code for anything newer than 2015. This won't be as big an issue when 2018 CPS tax units are available, but someone could still want to project into the future.
Reaggregation aside, it seems intuitively inaccurate to assign different weights to tax units within the same household.
Suggestion
Would it be possible to add constraints to the weighting and aging routines to ensure that tax units within the same household have the same weight?
The text was updated successfully, but these errors were encountered: