I don't think this would be too bad, and useful preparation for making the MLJ model interface more flexible later.
The MLJTuning API doesn't really touch on this point. A tuning strategy needs to implement a models method to generate models to evaluate, but doesn't say how the models are generated. They needn't be mutations of a single object. However, the MLJ model interface currently states that models must be mutable, so some tuning strategies do use mutation to generate their models.
TODO:
[ ] To see if the change would be breaking, update this table:
Some context: https://github.com/JuliaML/TableTransforms.jl/issues/67
I don't think this would be too bad, and useful preparation for making the MLJ model interface more flexible later.
The MLJTuning API doesn't really touch on this point. A tuning strategy needs to implement a
modelsmethod to generate models to evaluate, but doesn't say how the models are generated. They needn't be mutations of a single object. However, the MLJ model interface currently states that models must be mutable, so some tuning strategies do use mutation to generate their models.TODO:
GridRandomSearchLatinHypercubeMLJTreeParzenTuning()ParticleSwarmAdaptiveParticleSwarmExplicit()cc @juliohm