Map the stored WIC take-up draw (would_claim_wic) onto takes_up_wic_if_eligible when loading US data
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 64/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- backend, data-engineering
Research direction
Start with PolicyEngineUSLatest._build_simulation_from_dataset, then trace managed_microsimulation and create_datasets to compare their loading behavior. Check the manifest-pinned dataset and the microcosm#1026 findings for the stored column and expected WIC totals. Done means the legacy draw maps for every dataset year when the new input is absent, while an existing takes_up_wic_if_eligible column takes precedence.
Written by the indexing model from the issue text.
Description
policyengine-us 2.2.1 (this package's US pin) has no variable would_claim_wic. Its WIC take-up input is takes_up_wic_if_eligible (Person, MONTH, default_value = True), and wic is defined_for it.
The certified US default, populace-us-2024-spm-20260915 (pinned in src/policyengine/data/bundle/manifest.json), stores the seeded take-up draw as would_claim_wic only. Both US load paths skip a stored column the engine does not define, so the draw is dropped and every WIC-eligible person takes WIC up:
PolicyEngineUSLatest._build_simulation_from_datasetsets inputs only for columns insystem.variables;managed_microsimulationandcreate_datasetshand the file topolicyengine_us.Microsimulation, whose loader skips unknown columns.
PolicyEngine/microcosm#1026 measured 2024 WIC at $11.52B with the draw ignored and $6.63B with it restored (published runtime: $6.68B), and 12.65M vs 6.66M recipients.
Fix (option 2 of microcosm#1026): when loading, if the data stores would_claim_wic, the engine does not define it but does define takes_up_wic_if_eligible, and the data does not already store takes_up_wic_if_eligible, set the live input from the stored draw for every month of every dataset year. The mapping should retire itself once the data carries the new name.
- Dominant language
- Python
- Stars
- 7
- Forks
- 9
- Avg merge
- 14h 49m
- Merged PRs (30d)
- 9
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PolicyEngine/policyengine.py
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PolicyEngine/policyengine.py#473 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
PolicyEngine/policyengine.py#436 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PolicyEngine/policyengine.py#408 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
PolicyEngine/policyengine.py#532 ·
Maintainers usually reply within 1 day
-
Design note: a weighted module inside policyengine.py, replacing the microdf dependencyPossibly taken @MaxGhenis claimed this 6 days ago. Open
PolicyEngine/policyengine.py#528 · 1 assignee ·
Maintainers usually reply within 1 day
All issues in PolicyEngine/policyengine.py
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-2 days Newbie friendliness 70/100
-
FingerprintSplitter raises ZeroDivisionError when int(frac_train * len(dataset)) floors to zeroOpen
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 7 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
lmstudio-ai/mlx-engine#376 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
pyiron/bagofholding#166 ·