Have `train!` record, for inclusion in output, a history of the public state of every control
@ablaom ya está trabajando en esto.
Desde el 7/10/2026.
Evaluación
Este issue todavía no se ha evaluado.
Descripción
I propose some enhancements to address two main shortcomings of IterationControl.jl, mostly based on working on tutorials for MLJIteration.jl (which wraps MLJ models in the controls provided by IterationControl.jl):
-
While possible in practice, it is rather complicated to do things like: (i) Get a history of losses (or training losses) for training over multiple iterations (see #47); and (i) Set up a callback to record, say, evolution of some learned parameters. In both cases, you have to define and initialise containers to store the relevant trace, and also to arrange the relevant callback control to write to that container as training proceeds. When you repeat the experiment, you may need to flush the trace containers. This is inconvenient.
-
The internal state of a control is currently considered private API and the only interface point is for accessing what, from the final state, is returned in the "report" output by "train!". This seems unnecessarily opaque.
-
The "report" returned by "train!" is quite hard to grok, without delving into docs or scratching your head.
I propose:
-
Introduce a new method
public_state(control, state)that exposes everything aboutstatethat might be useful to know at every control cycle, in a human readable form (named tuple, say) -
By default, have
train!record a complete history of the public state of each control, exposed in the report, with acompact=trueoption to just record final state (for the atypical case fallbacks are exposing large objects as part of state) -
Make improvements to the structure and display of the report to make access more intuitive.
Among other things, these changes would likely address #62 and #47.
These changes would be necessarily breaking, although the logic of controls themselves would not change much, if at all.
Some steps required are:
- Introduce
public_statethe more primitive level ofEarlyStopping.jl(a dep of IterationControl.jl).
- Lenguaje dominante
- Julia
- Estrellas
- 25
- Forks
- 1
- Merge medio
- 35 min
- PR fusionados (30 d)
- 1
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 JuliaAI/IterationControl.jl
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 15/100
JuliaAI/IterationControl.jl#63 · 1 comentario ·
-
next breaking release
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
Remove unnecessary restriction that a callback function `<:Function`. That is, allow any callable.Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
JuliaAI/IterationControl.jl#58 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
JuliaAI/IterationControl.jl#47 · 1 comentario ·
Todos los issues de JuliaAI/IterationControl.jl
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
JuliaGPU/KernelAbstractions.jl#897 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
oscar-system/GAP.jl#1455 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
JuliaAI/MLJTransforms.jl#85 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
SciML/OrdinaryDiffEq.jl#4875 ·
Los mantenedores suelen responder en 4 días