This stategy (originally added for testing purposed only) is has not been publicised, but needs some improvements before doing so:
Problems:
Currently the explicit list (or iterator) of models is specified as range and all models need to have the same type - which is extremely restrictive, as the main use case is for evaluating multiple models of different types.
Currently the user has to specify somemodel=... , say the first in the list, which is clunky
Suggested resolution:
Add a new keyword models=... whose specification flags the strategy automatically as Explicit, and whose value is the iterator of models to be compared. Internally models is copied to range. An error is thrown if models and range are both specified and not the same, or if model and models are both specified but model isa eltyype(models) is not true. This maintains backwards compatibility.
Implementation:
To get around the design issue requiring all models to have the same type, we can apply a thin wrapper to all models in the list and give a wrapped model the same setproperty!/getproperty interface as the original. The alternative (I'm guessing, from memory) is to remove the model type parameter M from MLJBase.Resampler{M} which could be painful, but worth checking as this would be less of a hack. Any loss of performance in dropping the type parameter is likely trivial in 99% of use cases.
This stategy (originally added for testing purposed only) is has not been publicised, but needs some improvements before doing so:
Problems:
Currently the explicit list (or iterator) of models is specified as
range
and all models need to have the same type - which is extremely restrictive, as the main use case is for evaluating multiple models of different types.Currently the user has to specify some
model=...
, say the first in the list, which is clunkySuggested resolution:
models=...
whose specification flags the strategy automatically asExplicit
, and whose value is the iterator of models to be compared. Internallymodels
is copied torange
. An error is thrown ifmodels
andrange
are both specified and not the same, or ifmodel
andmodels
are both specified butmodel isa eltyype(models)
is not true. This maintains backwards compatibility.Implementation:
To get around the design issue requiring all models to have the same type, we can apply a thin wrapper to all models in the list and give a wrapped model the same setproperty!/getproperty interface as the original. The alternative (I'm guessing, from memory) is to remove the model type parameter
M
fromMLJBase.Resampler{M}
which could be painful, but worth checking as this would be less of a hack. Any loss of performance in dropping the type parameter is likely trivial in 99% of use cases.