-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the need to annotate supervised models with a fitresult type #93
Comments
Progress report: I have benchmarked 9 atomic models in ensembles of size 500, run on the existing code and smarter alternative code that does not need the fitrestult types (see below). The only statistically significant differences detected are, from a practical point of view, slight. The So I will be proceeding with the refactoring of MLJBase, MLJ, MLJModels to eliminate the pesky fit-result type requirement. This will simplify the model interface and eliminate some confusion. This refactoring does not effect regular MLJ users, except advanced users building learning networks, and only in a miniscule way. I hope to have the changes ready in 2-4 days. I am sorry I did not get this right from the beginning. This represents some of the earliest code I wrote for Koala. run on alternative code (no use of atomic model fit-result type)
run on master (using declared fit result type)
|
Resolved on all MLJBase/MLJModels/MLJ master branches. Live in upcoming releases 0.2.0, 0.2.0, 0.2.0, respectively |
Recall that presently one is required to declare the type of
fitresult
returned by a supervised model'sfit
method in the modelstruct
declaration, as in:One is allowed to use
Any
as the fitresult type, but for efficient ensembling of your model this should be concrete. This is a pain point because the concrete type can be quite complicated. It also may depend on the data and/or hyperparameters in ways that are difficult to anticipate - DecisionTree.jl is a case-in-point - although this is arguably a design flaw at the level of the algorthim being wrapped.There may be other reasons for declaring this type but I think ensembling is the main one. However, on reviewing ensembling (a legacy of Koala), I don't see why the type could not be inferred by the compiler if this code is refactored appropriately, and we could potentially simplify the API.
Investigating this is not currently a priority for me, but I am optimistically opening this issue anyway. For now I think model API implementers should feel free to declare their fitresult types as
Any
.The text was updated successfully, but these errors were encountered: