ablaom
commented
4 years ago Yes, basically the report and fitted_parmams model interface points are underexploited in many existing implementations. Would be great to see improvement here.
Regarding documentation of what report and fitted_params provide: I think the fact these are named tuples makes them a little bit self-documenting. Details should go either in the Model struct docstring (don't know how that works for structs defined by macros). Generally, however, the source package should provide documentation about these things and a suggestive key name should be enough, no?
Generally, I don't think we should (yet) be in the business of reporting derived statistics that the package itself does not compute or document. Rather, we should refer requests for functionality to the external package authors, and then update our interfaces, if we have provided these in-house.
Regarding printing out decision trees, I have made a concrete suggestion here: https://discourse.julialang.org /t/how-to-visualise-the-structure-of-the-decision-tree-built-by-mlj/30946/5 and opened a corresponding issue just now: https://github.com/alan-turing-institute/MLJ.jl/issues/347
up to know little care has been attached to providing good support to "fitted_params" and "report" in favour of "just having more models" and focusing on the fit/predict/transform dance. Now that we actually have more models, it might do us good to revisit and make sure that we can convenientely inspect the trained models. Below a few examples of things that could be done one way or another:
principalvars ./ tvarbut that's not straightforward for an outsider (+ no docstring)thoughts?