MLJBase.jl icon indicating copy to clipboard operation
MLJBase.jl copied to clipboard

Fallback implementation of `implemented_methods(model)` doesn't really work.

Open ablaom opened this issue 4 years ago • 0 comments

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.

Thoughts anyone?

Related: (https://discourse.julialang.org/t/how-do-a-i-get-a-type-stripped-of-parameters/73465/11)

ablaom avatar Jan 07 '22 04:01 ablaom