Just remembered that our implementation currently only stores node values for terminal nodes. We would need an option to compute the node values for non-terminal nodes too.

Another idea is that trees don't need to be explicitly pruned. It would be easier/faster to add max_depth, min_samples_split and min_samples_leaf options directly to the apply and predict method of Tree. When evaluating a tree, we can just return the current node value when max_depth, min_samples_split and min_samples_leaf are satisfied.

This would not work for min_samples_leaf, as this criteria might discard
splits that may have been better otherwise. Eg, an unbalanced split of
the root.

Le 13 sept. 2014 04:18, "Mathieu Blondel" notifications@github.com a
écrit :

Just remembered that our implementation currently only stores node values
for terminal nodes. We would need an option to compute the node values for
non-terminal nodes too.

Another idea is that trees don't need to be explicitly pruned. It would
be easier/faster to add max_depth, min_samples_split and min_samples_leaf
options directly to the apply and predict method of Tree. When evaluating a
tree, we can just return the current node value when max_depth,
min_samples_split and min_samples_leaf are satisfied.

—
Reply to this email directly or view it on GitHub.

Just remembered that our implementation currently only stores node values for terminal nodes. We would need an option to compute the node values for non-terminal nodes too.

This is now no longer true :)

I don't think we're adding CV classes for random forests, and the idea of warm_start is discussed in other places. So closing this one.