Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Incorrect lagged income quintiles after benefit-unit changes

Aperta
  • Qualcosa non va?
#543 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
backend, databases

Direzione di ricerca

Start with Person.getYHhQuintilesMonthC5L1() in src/main/java/simpaths/model/Person.java, the Q2–Q5 dummy getters, and new benefit unit initialization in src/main/java/simpaths/model/BenefitUnit.java. Trace how a person's benefit unit changes and decide how individual lagged quintile history should be retained, including how missing history is handled. Add focused checks for unchanged membership, a new unit at age 18, and partnership formation between people with different quintiles.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Coding problem

A person's lagged income quintile should describe the benefit unit they belonged to in the previous period. Instead, Person.getYHhQuintilesMonthC5L1() reads the lag stored on their current benefit unit:

return benefitUnit.getYHhQuintilesMonthC5L1();

When someone forms a new benefit unit, for example on turning 18 or forming a partnership, that unit may have no previous-period quintile. The Q2-Q5 dummy getters then all return zero, silently applying the Q1 reference-category coding. This is not evidence that the person was previously in Q1.

The new-unit initialisation supplies Q3 for a missing current quintile, but does not restore the person's previous quintile.

Verification

In a clean build of develop at 11bec2bd9 (23 October), an isolated getter test returned:

  • Original benefit unit with lagged Q5: Q5.
  • Membership changed to a new unit without history: null, with all Q2-Q5 dummy values 0.
  • Destination unit given lagged Q2: Q2, rather than the person's original Q5.

The same behaviour occurs in the saved income-validation JAR. These checks establish the getter problem; they do not measure its population frequency or aggregate effect on predictions.

Proposed coding repair

The approach discussed was to preserve each person's BU income quintile at the individual level before membership changes, and use that stored previous-period value for the lagged regressor. Two people forming a couple could then correctly retain different lagged quintiles. Retaining the previous BU link and its historical value is an alternative.

A focused test would check unchanged membership, a new BU at age 18, and partnership formation between people from different quintiles. Missing history would also need explicit handling rather than silently becoming the reference category. This repair preserves the meaning of the existing regressor; it does not itself require replacing it with parental income.

Separate education-specification question

Even with the coding repair, a student may subsequently have low own-BU income while still living with well-off parents. Whether E1a should instead use parental income, and how E1b should distinguish own from parental resources, is a separate specification decision requiring consistent estimation and Java implementation.

This issue is about preserving individual history, not choosing those education specifications or imputing parental income. It is also distinct from the equivalence-scale error in #541.

Could we confirm the preferred implementation and who will take it forward?

Lingua principale
Java
Stelle
26
Fork
38
Merge medio
13h 5m
PR unite (30g)
7

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di simpaths/SimPaths

Tutte le issue di simpaths/SimPaths

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.