MNT `_weighted_percentile` supports np.nan values #29034

StefanieSenger · 2024-05-16T23:00:44Z

What does this implement/fix? Explain your changes.

This PR adds support for nan input into _weighted_percentile, which is used within SplineTransformer, for instance.

Any other comments?

This is for @ogrisel since we had talked about that:

This does not deliver equivalent results as np.nanpercentile in the current dev-version, because they were different before: _weighted_percentile is finding the next lower percentile, while np.nanpercentile seems to find their percentiles differently (closest?). The more variance in the sample_weights, the more important the effect of this gets.

Here an example without any nans and without weights:

import numpy as np
from sklearn.utils.stats import _weighted_percentile

percentile = 66
arr2D = np.array([[3,30],[1,20],[3,10]])
weights2D = np.array([[1,1],[1,1],[1,1]])
print(_weighted_percentile(arr2D, weights2D, percentile))
print(np.nanpercentile(arr2D, percentile, weights=weights2D, axis=0, method="inverted_cdf"))

output:

[3 20]
[3 30]

While setting percentile = 67 leads to the same results.

Edit: What I wrote is actually not true. The differing output was due to not putting sample weights of nan values to 0 before. Now that is done, we have the same results it seems.

github-actions · 2024-05-16T23:01:59Z

✔️ Linting Passed

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

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

ogrisel

Some early feedback.

sklearn/utils/stats.py

sklearn/utils/tests/test_stats.py

ogrisel · 2024-05-21T16:01:59Z

sklearn/utils/stats.py

+                "One feature contains too many NaN values. This error should "
+                "actually either raise within the API, or there needs to be some "
+                "validation here before to make sure it cannot happen."
+            )


I think it's fine to return np.nan valued percentile (maybe with a warning?) if some array is all-nan valued.

I agree and have removed this from here (and also repaired the buggy loop).

But some further thoughts, that I am not sure how important they are to be taken:

The reason I had put it here was that I had tested this on the branch from the nans in SplineTransformer PR where we add test_spline_transformer_handles_all_nans (quite a special case anyway) and this made it raise in a not very informative way.

I think the error needs to be handled somehow, but within SplineTransformer, so that _weighted_percentile can stay flexible in case it's used differently in another context at one point.

For the other cases, we could raise a warning similar to like its done in numpy:

/home/stefanie/.pyenv/versions/3.12.2/envs/scikit-learn_dev/lib/python3.12/site-packages/numpy/lib/_nanfunctions_impl.py:1623: RuntimeWarning: All-NaN slice encountered return fnb._ureduce(a, ...

But should we add a warning within a private method? I'm a bit hesitant, as this could be confusing for the users who might not be aware about _weighted_percentile being internally used. Maybe this warning should instead be raised withing the realm of whatever API method is using it if need be. Candidates might be AbsoluteError.fit_intercept_only(), PinballLoss.fit_intercept_only(), HuberLoss.fit_intercept_only(), KBinsDiscretizer.fit() and maybe I should add similar all-nan-column tests and see if they raise or if we want to add a warning. Does that make sense?

I have looked at this again and went through all the places where _weighted_percentile gets used.

The losses I mentioned above (only internal use) as well as set_huber_delta() and median_absolute_error() find a percentile from within y_true or y_true-some_other_1darray , where I think it should be pretty obvious for the user if all values were nan. This is why I think it's okay without a warning.

KBinsDiscretizer and SplineTransformer use it on the whole X within their fit methods and I think we could add a warning there for all-nan-columns if this kind of validation is not already done somewhere else.

When _weighted_percentile is called by the loss functions, we can expect that there will never be any nan values in y_true because the public method of the estimator (typically .fit) always checks that there are no nan values and raise an exception if needed before calling _weighted_percentile:

>>> from sklearn.datasets import make_regression >>> import numpy as np >>> from sklearn.linear_model import QuantileRegressor >>> X, y = make_regression() >>> y[0] = np.nan >>> QuantileRegressor().fit(X, y) Traceback (most recent call last): Cell In[14], line 1 QuantileRegressor().fit(X, y) File ~/code/scikit-learn/sklearn/base.py:1514 in wrapper return fit_method(estimator, *args, **kwargs) File ~/code/scikit-learn/sklearn/linear_model/_quantile.py:163 in fit X, y = self._validate_data( File ~/code/scikit-learn/sklearn/base.py:650 in _validate_data X, y = check_X_y(X, y, **check_params) File ~/code/scikit-learn/sklearn/utils/validation.py:1286 in check_X_y y = _check_y(y, multi_output=multi_output, y_numeric=y_numeric, estimator=estimator) File ~/code/scikit-learn/sklearn/utils/validation.py:1308 in _check_y _assert_all_finite(y, input_name="y", estimator_name=estimator_name) File ~/code/scikit-learn/sklearn/utils/validation.py:123 in _assert_all_finite _assert_all_finite_element_wise( File ~/code/scikit-learn/sklearn/utils/validation.py:172 in _assert_all_finite_element_wise raise ValueError(msg_err) ValueError: Input y contains NaN.

and similarly for public scoring functions that rely on those losses:

>>> from sklearn.metrics import mean_pinball_loss >>> mean_pinball_loss(y, y) Traceback (most recent call last): Cell In[16], line 1 mean_pinball_loss(y, y) File ~/code/scikit-learn/sklearn/utils/_param_validation.py:213 in wrapper return func(*args, **kwargs) File ~/code/scikit-learn/sklearn/metrics/_regression.py:318 in mean_pinball_loss y_type, y_true, y_pred, multioutput = _check_reg_targets( File ~/code/scikit-learn/sklearn/metrics/_regression.py:112 in _check_reg_targets y_true = check_array(y_true, ensure_2d=False, dtype=dtype) File ~/code/scikit-learn/sklearn/utils/validation.py:1056 in check_array _assert_all_finite( File ~/code/scikit-learn/sklearn/utils/validation.py:123 in _assert_all_finite _assert_all_finite_element_wise( File ~/code/scikit-learn/sklearn/utils/validation.py:172 in _assert_all_finite_element_wise raise ValueError(msg_err) ValueError: Input contains NaN.

Still we might want to add a nan_policy parameter to _weighted_percentile with "raise" and "omit" as possible options as scipy does:

https://github.com/scipy/scipy/blob/main/doc/source/dev/api-dev/nan_policy.rst#L70

This would make the use of _weighted_percentile within or code base more explicit: loss functions would call it with nan_policy="error" (the default) while transformers such as SplineTransformer that actually need nan support would call it with nan_policy="omit".

WDYT?

I think that the occasion when we would want to raise (all values from a column being nans) is so edge, that we should not have a param in _weighted_percentile for it.

Having something like scipys nan_policy would be a larger design decision for the whole project and having it for our little purpose seems like an overkill to me, also because np.nanpercentile will be the future in a determined time anyways.

For the other cases, when there are only a few nan values, the users can express their intend in SplineTransformer.fit() with handle_missing='zeros' (once #28043 is merged). If they don't explicitly express this wish, the fit method would raise earlier, so there would be no reason to deselect _weighted_percentiles nan-dealing behaviour.

KBinsDiscretizer, which is a special case of SplineTransformer, currently cannot be used with nan values. If it will also get nan support, then probably like in the former.

And it seems to me there is no other method or function that would implicitly (without user intend) allow nans AND use _weighted_percentile internally.

Does my reasoning make sense?

Having something like scipys nan_policy would be a larger design decision for the whole project and having it for our little purpose seems like an overkill to me, also because np.nanpercentile will be the future in a determined time anyways.

If we introduce this just for private methods like _weighted_percentile, then it's fine. But indeed, this kind errors are better be raised by public methods because there are more likely to be able to output error messages with more informative contextual details than generic private method would.

So ok for not introducing nan_policy as part of this PR.

Thank you, I'm relieved. And sorry if I expressed myself a bit strong there.

sklearn/utils/stats.py

…asked arrays

StefanieSenger

I am addressing your comments in my latest push, @ogrisel, thank you.

That test now fails because it is an actual test. Through it I got aware that we also need to mask out the nans for calculating the percentile_idx. Simply ignoring nans within the indexing tasks is not enough. I am still trying to figure out how to do that using masked arrays, pushing the current state of my attempts.

Edit: I now found out what I did wrong before, I had created the nan mask on the input array, and but it should have been the sorted one. With the corrected nan mask we can indeed calculate percentile_idx and using a masked array is not necessary anymore, it seems. I fixed the errors below and all the tests pass.

sklearn/utils/tests/test_stats.py

sklearn/utils/stats.py

ogrisel

Thanks @StefanieSenger for the PR.

I think the code could be made a bit easier to follow and a bit more efficient with the following suggestions but otherwise, this LGTM.

I realize that this code should be easily adaptable to work with array API (I think). This could be done in a follow-up PR. This would unblock several items of the list in #26024 that require quantile or percentile that is not yet standardized in the array API spec (data-apis/array-api#795). Let's do that in a follow-up PR.

sklearn/utils/tests/test_stats.py

sklearn/utils/stats.py

sklearn/utils/tests/test_stats.py

ogrisel · 2024-06-14T15:33:41Z

Note that what is done in this PR is one way to achieve the results that we want but it is not the only way.

The alternative to post-filtering nan percentile values would be to instead call the percentile computation on individual 1d sorted arrays by trimming the nans that should old be at the end of the 1d arrays. But since there is a variable number of nans per 1d array, then we would not be able to process the trimmed arrays as a single 2D stack datastructure of sorted values.

I think the current code in this PR is a less invasive change, however the 1d decomposition I suggest above would be more efficient when the data has many nans (because post-processing would do many iterations in this case).

Co-authored-by: Olivier Grisel <olivier.grisel@ensta.org>

StefanieSenger

Note that what is done in this PR is one way to achieve the results that we want but it is not the only way.

The alternative to post-filtering nan percentile values would be to instead call the percentile computation on individual 1d sorted arrays by trimming the nans that should old be at the end of the 1d arrays. But since there is a variable number of nans per 1d array, then we would not be able to process the trimmed arrays as a single 2D stack datastructure of sorted values.

I think the current code in this PR is a less invasive change, however the 1d decomposition I suggest above would be more efficient when the data has many nans (because post-processing would do many iterations in this case).

Yes, I was seeing this problem and couldn't think of a way to resolve this (after experimenting with masked arrays). There would not be an easy way to put the taken-apart array back together with keeping the rest of the order in check, or at least I couldn't think of any.

It would have helped me to talk about strategies in the beginning.

Since you have approved this PR, I assume despite being slower it's still alright how it is?

sklearn/utils/tests/test_stats.py

StefanieSenger · 2024-06-14T22:29:35Z

sklearn/utils/stats.py

+                "One feature contains too many NaN values. This error should "
+                "actually either raise within the API, or there needs to be some "
+                "validation here before to make sure it cannot happen."
+            )


Thank you, I'm relieved. And sorry if I expressed myself a bit strong there.

ogrisel · 2024-06-19T15:51:03Z

Since you have approved this PR, I assume despite being slower it's still alright how it is?

I am not so sure. I would love to have a second opinion on this matter. Maybe it would help to measure the time it takes to call _weighted_percentile on an array with int(1e7) random values with 0 occurrence of np.nan vs 50% vs all nans. For instance using %timeit in an IPython or Jupyter notebook session.

sklearn/utils/tests/test_stats.py

StefanieSenger · 2024-06-20T10:26:12Z

I am not so sure. I would love to have a second opinion on this matter. Maybe it would help to measure the time it takes to call _weighted_percentile on an array with int(1e7) random values with 0 occurrence of np.nan vs 50% vs all nans. For instance using %timeit in an IPython or Jupyter notebook session.

I see, I have made this performance test in a jupyter notebook (I hope it's correct) and the results look like this:

import time
import numpy as np
from sklearn.utils.stats import _weighted_percentile

def test_performance(X, sample_weight):
    start = time.time()
    _weighted_percentile(X, sample_weight)
    stop = time.time()

    return stop - start

###### test without nans #####
rng = np.random.RandomState(42)
X = rng.rand(100, 100) #int(1e7) is fulfilled here, I believe
sample_weight = np.ones_like(X)

res = 0
for i in range(10000):
    res += test_performance(X, sample_weight)

res
# 4.266921281814575

###### test with nans #####
X[rng.rand(*X.shape) < 0.5] = np.nan

res = 0
for i in range(10000):
    res += test_performance(X, sample_weight)

res
# 5.107046365737915

It is slower when it has to sort out the percentile across 100 columns in the end. I think the number of columns would influence the result strongly. I don't really have a feeling for determining if this performance drop is acceptable or not. But maybe this can help another maintainer form an opinion. Please tell me if I should push the notebook somewhere (but there is no more code than this).

Co-authored-by: Olivier Grisel <olivier.grisel@ensta.org>

ogrisel · 2024-06-28T12:49:33Z

Thanks for the analysis, but I meant to run on a large 1D array with int(1e7) elements to be able to probe the scalability. I tried in the following, and it can be too slow, so I adapted the benchmark to run on 1 million (int(1e6)) elements instead.

Here is an adapted benchmark:

# %%
import time
import numpy as np
from sklearn.utils.stats import _weighted_percentile


def test_performance(func, *args, n_calls=10, **kwargs):
    start = time.time()
    for _ in range(n_calls):
        func(*args, **kwargs)
    stop = time.time()

    return (stop - start) / n_calls

# %%
rng = np.random.RandomState(42)
X = rng.rand(int(1e6))
sample_weight = np.ones_like(X)
test_performance(_weighted_percentile, X, sample_weight, n_calls=5)
# 0.10989542007446289

# %%
X_few_nan = X.copy()
X_few_nan[rng.rand(*X.shape) < 0.1] = np.nan
test_performance(_weighted_percentile, X_few_nan, sample_weight, n_calls=5)
# 0.10001721382141113

# %%
X_half_nan = X.copy()
X_half_nan[rng.rand(*X.shape) < 0.5] = np.nan
test_performance(_weighted_percentile, X_half_nan, sample_weight, n_calls=5)
# 0.07429156303405762

# %%
X_many_nan = X.copy()
X_many_nan[rng.rand(*X.shape) < 0.9] = np.nan
test_performance(_weighted_percentile, X_many_nan, sample_weight, n_calls=5)
# 0.04319744110107422

# %%
X_all_nan = np.full_like(X, np.nan)
test_performance(_weighted_percentile, X_all_nan, sample_weight, n_calls=5)
# 5.420448541641235

So interestingly, the duration can decrease when adding nan values to X. One would need to confirm with a profiler such as viztracer for instance, but I suspect that happens because argsorting with many repeated values (the nans) is easier hence faster and the gain in speed obtained by sorting is larger than the extra cost of post-processing the nans percentiles.

However, it's quite catastrophic for the "all nans" edge case with a 50x slow-down...

So based on those results I would rather not merge the PR as it is and instead implement one of the following two approaches:

detect all nans columns and skip the nan-post processing for them while keeping the rest of the PR,
refactor the code of _weighted_percentile to implement per-columns filtering of the nan values of X before calling np.argsort on each of the filtered columns of X. This way, no nan-specific post-processing would be needed.

I have the feeling that the second would be more maintainable / readable.

Feel free to open a second PR if you want to explore both options and compare their performance.

StefanieSenger · 2025-01-17T12:00:50Z

Now after #30661 got merged, all the tests pass here.

@lorentzenchr, is this PR ready for merge now?

lorentzenchr · 2025-01-17T13:20:10Z

@lorentzenchr, is this PR ready for merge now?

I'll approve when a test vs numpy's weighted quantile function is added.

StefanieSenger · 2025-01-17T13:34:35Z

I'll approve when a test vs numpy's weighted quantile function is added.

Oh yes, sorry I forgot that.
I will ping you once it's added.

StefanieSenger · 2025-01-20T13:14:23Z

I've added tests that I think fit what you were thinking of. Would you have a look, @lorentzenchr ?

lorentzenchr · 2025-02-10T12:48:40Z

I'll soon have a final look.

lorentzenchr · 2025-02-14T20:01:06Z

sklearn/utils/tests/test_stats.py

+        ),
+    ],
+)
+def test_weighted_percentile_like_numpy_quantile(percentile, arr, weights):


For this test and the next one, I would prefer data generated in a manner similar to test_weighted_percentile_nan_filtered, i.e. larger more diverse data.

Yes, I agree. I have addressed this in my latest commit.

(With the larger data, my feeling would be that the parametrisation for percentile is not necessary anymore. Leaving this for you to judge.)

lorentzenchr

Apart from the above comment, LGTM.
@StefanieSenger Thanks for your endurance.

Note that meanwhile scipy has it's own array API compatible quantile function, see scipy/scipy#22352.

ogrisel · 2025-02-28T11:19:01Z

Note that meanwhile scipy has it's own array API compatible quantile function, see scipy/scipy#22352.

Interesting. I think we might want to consolidate our work there in the medium term. In the short term, I think it's worth merging this PR as is, once the tests have been updated as suggested in #29034 (review).

As far as I understand, what we are missing from scipy's implementation are the following:

the symmetrized version of the inverted_cdf strategy, which we implemented as _averaged_weighted_percentile and implemented as _averaged_weighted_percentile in Fix sample weight passing in KBinsDiscretizer #29907 and to be optimized as suggested in REF: Integrate symmetrization in _weighted_percentile to avoid double sorting #30894.
weight support for inverted_cdf and averaged_inverted_cdf.

ogrisel · 2025-03-03T17:23:44Z

I resynced this PR with main and marked for auto-merge if the tests are still green. Thanks all!

…it-learn into _weighted_percentile

nan support for _weighted_percentile

9b99ece

github-actions bot added the module:utils label May 16, 2024

StefanieSenger added 2 commits May 17, 2024 10:01

add condition to handle all nan features

37638e3

add test

6310d87

StefanieSenger changed the title ~~ENH _weighted_percentile supports np.nan values~~ MNT _weighted_percentile supports np.nan values May 17, 2024

ogrisel reviewed May 21, 2024

View reviewed changes

StefanieSenger added 2 commits May 24, 2024 13:21

return nan percentiles if thats the only choice, not raise error

13c3114

proper stop condition for while loop

ed8d6ca

StefanieSenger commented May 24, 2024

View reviewed changes

sklearn/utils/stats.py Outdated Show resolved Hide resolved

StefanieSenger added 2 commits May 24, 2024 14:36

set weights for nans to 0

cb05c73

improve test, fix while loop condition, unfruitful experiments with m…

a864f5d

…asked arrays

StefanieSenger commented May 28, 2024

View reviewed changes

sklearn/utils/tests/test_stats.py Outdated Show resolved Hide resolved

sklearn/utils/stats.py Outdated Show resolved Hide resolved

StefanieSenger and others added 4 commits May 28, 2024 14:52

Merge branch 'main' into _weighted_percentile

1e5bcc3

three different fixes

c156819

add test for 1D sample_weight

07ab1b6

add test for redirecting nan percentiles

63dc932

StefanieSenger marked this pull request as ready for review May 29, 2024 13:22

ogrisel approved these changes Jun 13, 2024

View reviewed changes

StefanieSenger and others added 2 commits June 15, 2024 00:20

variable renaming

ec0c0fc

Apply suggestions from code review

fb6dc1a

Co-authored-by: Olivier Grisel <olivier.grisel@ensta.org>

StefanieSenger commented Jun 14, 2024

View reviewed changes

ogrisel reviewed Jun 19, 2024

View reviewed changes

sklearn/utils/tests/test_stats.py Outdated Show resolved Hide resolved

sklearn/utils/tests/test_stats.py Outdated Show resolved Hide resolved

StefanieSenger and others added 2 commits June 20, 2024 12:45

Apply suggestions from code review

9266a42

Co-authored-by: Olivier Grisel <olivier.grisel@ensta.org>

apply suggestion from code review

5896e44

Merge branch 'main' into _weighted_percentile

17c8881

Merge branch 'main' into _weighted_percentile

fe5de46

lorentzenchr mentioned this pull request Jan 17, 2025

RFC: array-agnostic quantile data-apis/array-api#795

Closed

StefanieSenger added 4 commits January 18, 2025 14:33

add test for equivalence with numpy.quantile

acb734c

replace version in versionchanged marker

5e0e5b7

add test with nanquantile

ca26f6f

skip test if numpy<2.0

94b15e5

StefanieSenger and others added 3 commits February 6, 2025 19:01

Merge branch 'main' into _weighted_percentile

e70b1e7

Merge branch 'main' into _weighted_percentile

bf54733

fix linting after merge conflict

24bbefc

rename param for _averaged_weighted_percentile as we do here

04ecb1e

lucyleeow mentioned this pull request Feb 12, 2025

Remove median_absolute_error from METRICS_WITHOUT_SAMPLE_WEIGHT #30787

Draft

lorentzenchr reviewed Feb 14, 2025

View reviewed changes

lorentzenchr approved these changes Feb 15, 2025

View reviewed changes

ogrisel mentioned this pull request Feb 25, 2025

REF: Integrate symmetrization in _weighted_percentile to avoid double sorting #30894

Closed

StefanieSenger and others added 2 commits March 3, 2025 13:42

test with larger, more diverse data

4b550da

Merge branch 'main' into _weighted_percentile

f75125d

ogrisel enabled auto-merge (squash) March 3, 2025 17:23

StefanieSenger added 2 commits March 4, 2025 08:42

empty commit to re-trigger CI

8d63af3

Merge branch '_weighted_percentile' of github.com:StefanieSenger/scik…

76e9882

…it-learn into _weighted_percentile

ogrisel merged commit d6334e1 into scikit-learn:main Mar 4, 2025
31 checks passed

github-project-automation bot moved this from In Progress to Done in Missing value and nan support Mar 4, 2025

StefanieSenger deleted the _weighted_percentile branch March 4, 2025 08:41

lucyleeow mentioned this pull request Mar 14, 2025

Add array API support for _weighted_percentile #29431

Merged

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MNT `_weighted_percentile` supports np.nan values #29034

MNT `_weighted_percentile` supports np.nan values #29034

StefanieSenger commented May 16, 2024 •

edited

Loading

github-actions bot commented May 16, 2024 •

edited

Loading

ogrisel left a comment •

edited

Loading

ogrisel May 21, 2024

StefanieSenger May 24, 2024 •

edited

Loading

StefanieSenger May 29, 2024

ogrisel Jun 4, 2024

StefanieSenger Jun 5, 2024 •

edited

Loading

ogrisel Jun 13, 2024

StefanieSenger Jun 14, 2024

StefanieSenger left a comment •

edited

Loading

ogrisel left a comment

ogrisel commented Jun 14, 2024 •

edited

Loading

StefanieSenger left a comment

StefanieSenger Jun 14, 2024

ogrisel commented Jun 19, 2024 •

edited

Loading

StefanieSenger commented Jun 20, 2024 •

edited

Loading

ogrisel commented Jun 28, 2024 •

edited

Loading

StefanieSenger commented Jan 17, 2025

lorentzenchr commented Jan 17, 2025

StefanieSenger commented Jan 17, 2025

StefanieSenger commented Jan 20, 2025 •

edited

Loading

lorentzenchr commented Feb 10, 2025

lorentzenchr Feb 14, 2025

StefanieSenger Mar 3, 2025

lorentzenchr left a comment

ogrisel commented Feb 28, 2025 •

edited

Loading

ogrisel commented Mar 3, 2025

MNT _weighted_percentile supports np.nan values #29034

MNT _weighted_percentile supports np.nan values #29034

Conversation

StefanieSenger commented May 16, 2024 • edited Loading

What does this implement/fix? Explain your changes.

Any other comments?

github-actions bot commented May 16, 2024 • edited Loading

✔️ Linting Passed

ogrisel left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

StefanieSenger May 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

StefanieSenger Jun 5, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

StefanieSenger left a comment • edited Loading

Choose a reason for hiding this comment

ogrisel left a comment

Choose a reason for hiding this comment

ogrisel commented Jun 14, 2024 • edited Loading

StefanieSenger left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ogrisel commented Jun 19, 2024 • edited Loading

StefanieSenger commented Jun 20, 2024 • edited Loading

ogrisel commented Jun 28, 2024 • edited Loading

StefanieSenger commented Jan 17, 2025

lorentzenchr commented Jan 17, 2025

StefanieSenger commented Jan 17, 2025

StefanieSenger commented Jan 20, 2025 • edited Loading

lorentzenchr commented Feb 10, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lorentzenchr left a comment

Choose a reason for hiding this comment

ogrisel commented Feb 28, 2025 • edited Loading

ogrisel commented Mar 3, 2025

MNT `_weighted_percentile` supports np.nan values #29034

MNT `_weighted_percentile` supports np.nan values #29034

StefanieSenger commented May 16, 2024 •

edited

Loading

github-actions bot commented May 16, 2024 •

edited

Loading

ogrisel left a comment •

edited

Loading

StefanieSenger May 24, 2024 •

edited

Loading

StefanieSenger Jun 5, 2024 •

edited

Loading

StefanieSenger left a comment •

edited

Loading

ogrisel commented Jun 14, 2024 •

edited

Loading

ogrisel commented Jun 19, 2024 •

edited

Loading

StefanieSenger commented Jun 20, 2024 •

edited

Loading

ogrisel commented Jun 28, 2024 •

edited

Loading

StefanieSenger commented Jan 20, 2025 •

edited

Loading

ogrisel commented Feb 28, 2025 •

edited

Loading