✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: ef7d10c. Link to the linter CI: here}

Note: My PR #32119 fixes the issue (even if it's not it's primary goal, so it might make sense to do a 1-line fix PR first ^^)

Ah ok. I had a quick look at the linked PRs from the issue and didn't realise that there was already a fix :-/

Do you have a nice unittest for this issue? Fitting a bunch of trees and checking that all of them get the right impurity/have enough splits seems a bit of a round about way of testing this :-/

Do you have a nice unittest for this issue?

See PR #32193 😄

Fitting a bunch of trees and checking that all of them get the right impurity/have enough splits seems a bit of a round about way of testing this

I personally love tests with many random inputs. Toy examples should only be used for debugging IMO. It's still good to have them as tests, as it makes it easy to debug regressions. But it's really not enough to build confidence.

I personally love tests with many random inputs. Toy examples should only be used for debugging IMO. It's still good to have them as tests, as it makes it easy to debug regressions. But it's really not enough to build confidence.

Unfortunately, such randomized tests are often costly to run so we need to strike a balance. Ideally, individual tests should last no longer than 1 s on a usual CI runner.

Slow test suites makes it painful to run the tests locally or wait for the CI to complete on a PR. It would further make the release process more horrible than it is, given the number of Python versions and architecture combinations that we support.

What about adding a function to _partitioner.pyx that instantiates a DensePartitioner so that we can access it directly, instead of via a decision tree? We already have _py_sort to expose sort for testing purposes.

Being able to directly instantiate the partitioner would have been useful during debugging as well. And we could more easily test it. What are the downsides? I think having the class itself as cdef has performance benefits(?), but I can't think of a downside in terms of performance. The only downside I can think of is more code :-/ WDYT @ogrisel ?

Asking cursor for a sketch of how to do this gives the following:

def _py_test_partition_samples_final(
    const float32_t[:, :] X,
    intp_t[::1] samples,
    intp_t feature,
    float64_t threshold,
    intp_t n_missing,
    const uint8_t[::1] missing_values_in_feature_mask,
):
    """Test helper to directly test partition_samples_final.
    
    This function is used for testing the partitioning logic when missing
    values are present. It creates a DensePartitioner and calls
    partition_samples_final.
    
    Parameters
    ----------
    X : array-like of shape (n_samples, n_features)
        The input data
    samples : array-like of shape (n_samples,)
        Sample indices to partition (modified in-place)
    feature : int
        The feature index to partition on
    threshold : float
        The threshold value for partitioning
    n_missing : int
        The number of missing values in this feature
    missing_values_in_feature_mask : array-like of shape (n_features,)
        Mask indicating which features have missing values
        
    Returns
    -------
    None
        The samples array is modified in-place
    """
    cdef float32_t[::1] feature_values = np.empty(len(samples), dtype=np.float32)
    cdef DensePartitioner partitioner = DensePartitioner(
        X, samples, feature_values, missing_values_in_feature_mask
    )
    
    partitioner.init_node_split(0, len(samples))
    partitioner.partition_samples_final(
        best_pos=0,  # Not used in the actual partitioning logic
        best_threshold=threshold,
        best_feature=feature,
        best_n_missing=n_missing,
    )

I have one drawback in mind, but that depends how you use it.

Assuming you're using this wrapper to write the non-regression test for your fix, here is what could happen: someone refactors the inner working of trees, and can't really translate your test to the new design, so they remove it (or rewrite a weaker/incorrect version), and introduce the regression. Not super likely, but it still make me prefer testing the top level API when I can.
And here I think it's not too hard. As I already said in #32351 (comment), I think the test you've wrote would be a pretty good test with just a few simple changes.

I went with trying ten different trees. I think this is a good compromise between catching the bug and not spending too much compute time on this bug (e.g. by using different seeds).

I updated with main and marked as auto merge.