Not that I disagree, but what is the reason for this change?

I was trying to make the tree construction more stable by automatically rescaling the sample weights. Nothing worked with much success (it just moved the issue to someplace else...), but this test failed a few times because of this. Using more samples made that test more stable.

Thanks for including my suggestion. I apologize for being pedantic, but I meant a scale of more like [1e-8, 1e-4, 1e-1, 1e1, 1e4, 1e8]. Do you think this test is sufficient?

Unfortunately, which such larger/smaller scale factors, tests dont pass anymore. Numerical discrepancies creep in, leading to slightly different impurity values... I am not sure we can do anything about that. (My idea was to internally scale down sample_weight by 1. / sample_weight.max(), but this just moves the numerical issues somewhere else...)

So for me this test is more a safeguard that nothing obviously wrong is happening, rather than a bulletproof test.

Ah, okay. Thanks for checking!

but 1e-4 would still work, right?

This line confuses me.
X_new.shape[1] == 3
So he first expression evaluates to True, which is cast to 1, which is less than X.shape[1] == 10
So the assert would hold even if X_new.shape[1] == 11. Actually it succeeds for all values of X_new.shape[1] as long as X.shape[1] > 1

I guess remove the 0 <?

woops :) This one has been there for long without anybody noticing

Why do you use assert_less over assert_array_almost_equal?

I find it easier to control the quality of the approximation, rather than having all single importance values match up to some digit (but doing this, I only require their mean to do so).