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

Make infection feedback a constructor option of the latent classes; remove `infection_process`

Aperta
#902 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 6 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
python
Ambito
api, backend

Direzione di ricerca

Start with pyrenew/latent/base.py and the sample methods and constructors in population_infections.py and subpopulation_infections.py; compare their current renewal calls with InfectionsWithFeedback.sample in infection_process.py. Then update the exports and tests listed in the issue, including builder and integration coverage. Done means both latent classes support the paired feedback options and preserve the documented behavior, while the standalone infection classes still pass their tests.

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

Descrizione

model pyrenew

Remove the InfectionProcess protocol and the infection_process constructor argument added in #847. Infection feedback becomes two optional constructor arguments of PopulationInfections and SubpopulationInfections, and each latent class defines its own renewal step.

Motivation
  • Only two renewal steps exist, and one contains the other. Feedback with strength 0 gives exactly plain renewal. A pluggable protocol is more general than the code needs.
  • Feedback should be easy to find. It should be a documented option of the latent class, not a separate object users must know to build.
  • Coupled models can't use the protocol. MobilitySubpopulationInfections (#901) needs the population fractions in its renewal step, which the protocol does not pass. Without the protocol, every latent class defines its renewal step the same way.
What the user writes

Today:

builder.configure_latent(
    PopulationInfections,
    ...,
    infection_process=InfectionsWithFeedback(
        name="infections",
        infection_feedback_strength=strength_rv,
        infection_feedback_pmf=feedback_pmf_rv,
    ),
)

After this change:

builder.configure_latent(
    PopulationInfections,
    ...,
    infection_feedback_strength_rv=strength_rv,
    infection_feedback_pmf_rv=feedback_pmf_rv,
)

SubpopulationInfections takes the same two arguments. Without feedback, nothing changes.

Behavior
  • Given the same random variables and seed, results are identical to passing infection_process=InfectionsWithFeedback(...) today.
  • Feedback is off unless both arguments are given. One without the other raises ValueError.
  • A feedback PMF whose length differs from the generation interval, or a strength that does not broadcast to the shape of Rt, raises ValueError with both shapes. Today the PMF case is a shape error from jnp.einsum.
  • Passing infection_process raises TypeError.
  • The recorded Rt used by the renewal equation is renamed: rt_single_effective to rt_single_adjusted, and rt_subpop_effective to rt_subpop_adjusted. "Adjusted" matches compute_infections_from_rt_with_feedback (Rt_raw in, Rt_adjusted out) and avoids a second meaning of "effective reproduction number". rt_single and rt_subpop (raw Rt) are unchanged.
  • Infections and InfectionsWithFeedback are unchanged; pyrenew-multisignal uses InfectionsWithFeedback directly.
Breaking change

infection_process, InfectionProcess, and the _effective sites were added in #847 (2026-07-01) and are in no tagged release. One CDC-internal project passes infection_process to SubpopulationInfections; it moves the two arguments onto the latent class and reads the renamed sites. The release notes show the before and after code and the site renames.

Order

Land before #901, which builds on the renewal step and names from this change.

Out of scope
  • Changing the feedback model.
  • Turning feedback on by default.
Lingua principale
Python
Stelle
30
Fork
11
Merge medio
6g 1h
PR unite (30g)
10

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 CDCgov/PyRenew

Tutte le issue di CDCgov/PyRenew

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.