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 trait is defined but not currently used anywhere in MLJ (and not part of the public API). No model overloads it, but it has a fallback using methodswith(typeof(model)).
Similar models may not implement the same operations. For example, some "clusterers" implement predict only, some predict and transform, and some no operation at all (as they do not generalise to new data). For this reason, this trait is actually important; if we move from types to traits, it will be essential.
It's actually quite difficult to define a fallback for this method - basically because methods are associated with types and not instances; the method may defined using abstract supertype, and not for the concrete type of which model is an instance. This is the case, for example, if the type is parametric. So, for example, the current implementation leads to the following "unexpected" behaviour for EvoTreesClassifier models, because it is a parametric type:
julia> Tree =@load EvoTreeClassifier verbosity=0;
julia>implemented_methods(Tree)
1-element Vector{Symbol}::predict
julia>implemented_methods(tree)
Any[]
Note also that fit does not appear as an implemented method at all, because (I believe) it is defined simultaneously for all the EvoTrees model types using a Union type - something like fit(Union{EvoTreeClassifier,EvoTreeRegressor,...}, ...) = ....
Note also that the current fallback is slow (about 4 seconds).
I'm of the view, then, that implementing this method should be the responsibility of any model API implementation, as I have not been able to think of a robust alternative.
This trait is defined but not currently used anywhere in MLJ (and not part of the public API). No model overloads it, but it has a fallback using
methodswith(typeof(model))
.Similar models may not implement the same operations. For example, some "clusterers" implement
predict
only, somepredict
andtransform
, and some no operation at all (as they do not generalise to new data). For this reason, this trait is actually important; if we move from types to traits, it will be essential.It's actually quite difficult to define a fallback for this method - basically because methods are associated with types and not instances; the method may defined using abstract supertype, and not for the concrete type of which
model
is an instance. This is the case, for example, if the type is parametric. So, for example, the current implementation leads to the following "unexpected" behaviour forEvoTreesClassifier
models, because it is a parametric type:Note also that
fit
does not appear as an implemented method at all, because (I believe) it is defined simultaneously for all the EvoTrees model types using aUnion
type - something likefit(Union{EvoTreeClassifier,EvoTreeRegressor,...}, ...) = ...
.Note also that the current fallback is slow (about 4 seconds).
I'm of the view, then, that implementing this method should be the responsibility of any model API implementation, as I have not been able to think of a robust alternative.
Thoughts anyone?
Related: (https://discourse.julialang.org/t/how-do-a-i-get-a-type-stripped-of-parameters/73465/11)
The text was updated successfully, but these errors were encountered: