Constraint checker can miss negative-consumption roots that satisfy the extended FOCs
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 43/100
Línea de trabajo
Start by reading the constraint checker and the initial-cohort root-finding code involved in the extended FOCs; the issue does not name specific files or tests. Trace which consumption object the checker validates versus the one that can become negative, and use the failing scenario from the anchoring work to verify that infeasible roots are rejected. Done means negative-consumption roots no longer pass the constraint check.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Splitting this out from #1189 at @marcelolafleur's suggestion.
While working on initial-wealth anchoring in #1189, @marcelolafleur found that when the anchor is updated inside the outer loop, the initial cohorts' root-finding can land on infeasible negative-consumption solutions that nonetheless pass the constraint check. From the PR description:
rescaling the households' initial wealth between outer-loop iterations -- even damped -- drives the initial cohorts' root-finding into infeasible negative-consumption roots that satisfy the extended FOCs and pass the constraint checker.
The gist: a root can satisfy the extended FOCs while implying negative consumption, and the constraint checker watches a different consumption object than the one that goes negative, so these roots are not caught. That means an infeasible solution can slip through silently.
This came up as a side effect of the anchoring work rather than something #1189 needs to fix, but it seems worth a dedicated look. @marcelolafleur offered to add more detail here.
- Lenguaje dominante
- Python
- Estrellas
- 85
- Forks
- 153
- Merge medio
- 1 d 19 h
- PR fusionados (30 d)
- 19
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de PSLmodels/OG-Core
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 57/100
PSLmodels/OG-Core#1218 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
Todos los issues de PSLmodels/OG-Core
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
igormcsouza/tether#278 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 91/100
aws-samples/sample-per-model-bedrock#803 ·
Los mantenedores suelen responder en 1 día
-
documentation p1
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
huggingface/accelerate#4511 ·
Los mantenedores suelen responder en 1 día
-
follow-up
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día