Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Incorrect lagged income quintiles after benefit-unit changes

Ouverte
  • Quelque chose ne va pas ?
#543 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
java
Domaine
backend, databases

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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?

Langage dominant
Java
Étoiles
26
Forks
38
Merge moyen
13 h 5 min
PR mergées (30 j)
7

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de simpaths/SimPaths

Toutes les issues de simpaths/SimPaths

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.