Why would _averaged_weighted_percentile not work when len(distinct_values) <= max_bins?

>>> import numpy as np
>>> from sklearn.utils.stats import _weighted_percentile, _averaged_weighted_percentile
>>> a = np.random.randint(0, 10, size=10000).astype(np.float64)
>>> max_bins = 30
>>> max_bins > np.unique(a).shape[0]
True
>>> np.array(
...     [_averaged_weighted_percentile(a, np.ones_like(a), percentile) for percentile in percentiles]
... )
array([0., 0., 0., 1., 1., 1., 1., 2., 2., 2., 3., 3., 3., 4., 4., 4., 5.,
       5., 5., 6., 6., 6., 7., 7., 7., 8., 8., 8., 9., 9., 9.])
>>> np.array(
...     [_weighted_percentile(a, np.ones_like(a), percentile) for percentile in percentiles]
... )
array([0., 0., 0., 1., 1., 1., 1., 2., 2., 2., 3., 3., 3., 4., 4., 4., 5.,
       5., 5., 6., 6., 6., 7., 7., 7., 8., 8., 8., 9., 9., 9.])

When distinct values are less than max_bins and sample weights are given we get a discrepancy between weighted and repeated under special cases (see test_zero_sample_weights_classification under test_gradient_boosting.py). Need to see what to do here.

The manual midpoints between distinct values in the weighted case is probably responsible for this discrepancy.

We should probably explore if it's possible to post process the output of _averaged_weighted_percentile to trim duplicated thresholds. If the number of trimmed thresholds is lower than max_bins then it might be possible to further post-process to recover thresholds that match the unweighted case by shifting the thresholds to use 0.5 midpoints.

Why is that?

We now compute the bin edges using np.percentile(..., method="averaged_inverted_cdf") instead of np.percentile(..., method="linear") (the default in numpy) when sample_weight=None.

This is necessary to get the weighted / repetition equivalence semantics for the sample_weight parameter.

Preserve current behavior with sample_weight=None.

Sampling with replacement is necessary to ensure the correct weight semantics: if you have a data point with a large weight, it might need to be resampled several times for the edges derived from computed on the subset to be identically distributed as what you would observe from an equivalent unweighted dataset but with repeated values.

But I agree we need a non-regression test for this: #29641 (comment)

Then we should weigh in the trade-offs between conserving the old behavior for sample_weight=None and maintainability.
I would favor to make a case distinction and sample without replacement when sw=None.

The problem is that keeping the linear interpolation makes it impossible to have test_binmapper_weighted_vs_repeated_equivalence pass which is the point of this PR. Without changing this, we cannot test that our sample weight correctly implement the semantics we look for.

We could/should keep replace=True if samples_weight is None.

I really disagree: this would break the statistical equivalence between sample_weight=None and sample_weight=np.ones(n_samples) (and again test_binmapper_weighted_vs_repeated_equivalence).

Please provide a better changelog entry:

• What exactly changes, in particular what will produce different estimators compared to the previous (now current) version of scikit-learn. I think we should even list this PR under the Changed models section.
• Do not mention private functions like _averaged_weighted_percentile.

@snath-xoc we need to add a dedicated entry in the "Changed models section" to explain that the way the HistGradientBoostingClassifier/Regressor compute their bin edges is slightly changed when fit with sample_weight=None.

I suppose this would be in addition to the changelog PR?

Could you please extend the tests to cover this line? Maybe we could a simple kstest on the distribution of the bin edges for a smallish value of subsample (e.g. 100 out of a dataset of 300 data points) and a few bins (e.g. 3 or 5) so that we ignore the non-independent multiple testing problem. We need the test to run fast enough (ideally under 1s) so we have to constrain ourselves in the number of rng repetitions, but since subsampled binning on a single column of data is quite cheap, I believe this is doable.