Anthony Blaom, PhD

@OkonSamuel Do you see obvious issues with the way multithreading is currently implemented in prediction? It's here: https://github.com/JuliaAI/DecisionTree.jl/blob/f57a15633f5aadadfc408a8d5e42836e1f011c3f/src/classification/main.jl#L468

@rikhuijzer I don't believe nested multithreading is an issue. This has been tested before in MLJTuning where optimization multithreading has within it resampling multithreading. My interpretation of the 1.9 changes...

> multi-target problems (the current implementation for regression trees does not allow for `features` that are not `Float64` - i.e., single targets). Do you mean `features` here or, rather, `labels`...

Right. Your interesting question is a little orthogonal to initial post, so addressing it [here](https://github.com/JuliaAI/DecisionTree.jl/issues/30#issuecomment-1489368333)

Thanks @sylviankahane for reporting. > ERROR: LoadError: UndefVarError: AbstractNode not defined My guess is that the version of AbstractTrees.jl in your package environment is not recent enough to be compatible...

I'm not sure this is provided by this package, but you can get it using the MLJ wrapper: [`IteratedModel` docs](https://alan-turing-institute.github.io/MLJ.jl/dev/controlling_iterative_models/) [MNIST / Flux example of iterative model control](https://github.com/FluxML/MLJFlux.jl/tree/dev/examples/mnist) Is this...

Mmm... I see warm restart has not been implemented for the wrapper, which will make run time very slow for large numbers of iterations. I've posted https://github.com/JuliaAI/MLJDecisionTreeInterface.jl/issues/40 in response.

Yes, I understand. I just don't think that functionality exists here. I'll leave the issue open, and perhaps someone will add it. For my part, I'd rather prioritise model-generic solutions...

> In the case of a random forest, things are a little more complicated. Is there any way around writing a custom build_forest function with a user-defined loss instead of...

Glad to hear about the progress. I think to reduce the maintenance burden on this package I'd prefer not to add model-generic functionality within the package itself. MLJ and other...