You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been requested for documentation purposes. Model wrappers include things like TunedModel and BalancedModel and the idea is that such wrappers should be more discoverable by adding them to the model registry, with a tag of "meta-algorithm"; they will then automatically appear in the "Model Browser" (and a planned modernisation of that).
Currently, wrappers are excluded from the registry for these technical reasons:
Model wrappers are typically instantiated by the user with a constructor with a different name from the type and the type returned depends on constructor arguments (usually the atomic model being wrapped). That is, there are multiple types associated with a single "wrapper". For example: we have TunedModel (public user constructor) returning DeterministicTunedModel or ProbabilisticTunedModel ("private" types). The registry is based around types not constructors, and it was deemed confusing listing these "private" types in the registry. Incidentally, documentation is generally attached to the constructor, not the types, but these are always the same for non-wrappers.
Model wrappers do not have a kwarg constructor with defaults for all hyperparameters, because a default for the atomic model being wrapped is problematic. This poses a problem in integration tests. This issue more easily remedied as model wrappers are flagged by a trait, so we can just explicitly exclude them from integration tests.
Proposed solution
With the current entrenched type hierarchy, there's no getting around multiple "private" types for a single wrapper (constructor). In the proposed solution, the user will see these private types in the registry, but clicking on them in the Model Browser will send them to the central "constructor" (public) documentation. I am proposing to add a new trait constructor(model) so that we get a mapping from types to constructors for documentation purposes. It doesn't need to be overloaded for regular models, only for the wrappers at this time. However, I am also keen on this solution because it is more natural in the more "functional" setting I have been exploring in LearnAPI, a re-imagining of the MLJModelInterface for the future.
No breaking changes are required, but we will still need to rollout [compat] lower bound updates for the packages depending on the new trait.
Alter MLJModelInterface.jl docstring trait, to return the document string associated with a model's constructor when this has been explicitly overloaded; otherwise return the type docstring as before. Add constructor trait MLJModelInterface.jl#201
Then we need to overload constructor for the wrappers in these packages, in the order stated:
Update MLJInterfaceTests.jl to explicitly exclude testing of wrappers (this suffices for MLJTestIntegration.jl) not needed
Update the ModelDescriptors.toml at MLJ/docs to include tags for the new wrappers. Regenerate MLJ documentation to update the Model Browser. Check integration tests at MLJ. New version: MLJ v0.20.6 JuliaRegistries/General#108360
The text was updated successfully, but these errors were encountered:
This has been requested for documentation purposes. Model wrappers include things like
TunedModel
andBalancedModel
and the idea is that such wrappers should be more discoverable by adding them to the model registry, with a tag of "meta-algorithm"; they will then automatically appear in the "Model Browser" (and a planned modernisation of that).Currently, wrappers are excluded from the registry for these technical reasons:
Model wrappers are typically instantiated by the user with a constructor with a different name from the type and the type returned depends on constructor arguments (usually the atomic model being wrapped). That is, there are multiple types associated with a single "wrapper". For example: we have
TunedModel
(public user constructor) returningDeterministicTunedModel
orProbabilisticTunedModel
("private" types). The registry is based around types not constructors, and it was deemed confusing listing these "private" types in the registry. Incidentally, documentation is generally attached to the constructor, not the types, but these are always the same for non-wrappers.Model wrappers do not have a kwarg constructor with defaults for all hyperparameters, because a default for the atomic model being wrapped is problematic. This poses a problem in integration tests. This issue more easily remedied as model wrappers are flagged by a trait, so we can just explicitly exclude them from integration tests.
Proposed solution
With the current entrenched type hierarchy, there's no getting around multiple "private" types for a single wrapper (constructor). In the proposed solution, the user will see these private types in the registry, but clicking on them in the Model Browser will send them to the central "constructor" (public) documentation.I am proposing to add a new traitconstructor(model)
so that we get a mapping from types to constructors for documentation purposes. It doesn't need to be overloaded for regular models, only for the wrappers at this time. However, I am also keen on this solution because it is more natural in the more "functional" setting I have been exploring in LearnAPI, a re-imagining of the MLJModelInterface for the future.No breaking changes are required, but we will still need to rollout [compat] lower bound updates for the packages depending on the new trait.
Planned implementation
constructor
trait StatisticalTraits.jl#27docstring
trait, to return the document string associated with a model's constructor when this has been explicitly overloaded; otherwise return the type docstring as before. Addconstructor
trait MLJModelInterface.jl#201Then we need to overload
constructor
for the wrappers in these packages, in the order stated:constructor
trait MLJBase.jl#980constructor
trait forTunedModel
types MLJTuning.jl#219, New version: MLJTuning v0.8.7 JuliaRegistries/General#108129constructor
trait for all model types MLJBalancing.jl#27, New version: MLJBalancing v0.1.5 JuliaRegistries/General#108275constructor
trait forIteratedModel
types MLJIteration.jl#62, New version: MLJIteration v0.6.2 JuliaRegistries/General#108128constructor
forRecursiveFeatureElimination
types FeatureSelection.jl#10, New version: FeatureSelection v0.1.1 JuliaRegistries/General#108277And finally:
Update MLJInterfaceTests.jl to explicitly exclude testing of wrappers (this suffices for MLJTestIntegration.jl)not neededThe text was updated successfully, but these errors were encountered: