Wrap trees using DecisionTree.wrap for more convenient display

[ablaom]

It's now possible to plot a tree using the TreeRecipe.jl package but the workflow is not very user-friendly, as trees first need to be wrapped.

Currently the raw decision tree is exposed as fitted_params(mach).tree. I propose we pre-wrap this object (with the feature names already embedded) and add an extra field fitted_params(mach).raw_tree for the original unwrapped object.

Then plotting a tree would be as simple as

using TreeRecipe, Plots
tree = fitted_params(mach).tree
plot(tree)

Thoughts anyone?

@roland-KA

Related: #23

[roland-KA]

That sounds indeed like a more user-friendly way to do it (in contrast to the more the piggy-back solution we have currently).

But one thing in this new workflow isn't quite clear to me. The wrap-function has been introduced, because the decision tree models (depending on implementation and application) don't have information about feature labels and/or class labels included in the model. So the intention of wrap was to "add" this information.

The workflow looks currently as follows:

• create model
• wrap additional information (which is not included in the model)
• plot

The new workflow would be:

• wrap (sort of)
• create model
• plot

But where (in which context) would wrap occur? Where would the information about class labels and/or feature labels come from?

[ablaom]

Where would the information about class labels and/or feature labels come from?

@roland-KA The user provides a the MLJ interface a table (with features names embedded) and a categorical target (in classication case). So MLJModelInterface.fit can just peel off this metadata, rather than ignoring it as present for recombination (wrapping) with the output of the call to DecisionTree.build_tree. Instead of returning the raw output as the learned parameters, it returns the wrapped output. No?

[roland-KA]

Ah, of course, they are there just getting ignored 🤦‍♂️. Well, then we have everything to make the workflow more user-friendly.