Talip7/scikit-learn-issues-multilabel huggingface dataset:
当selector = VarianceThreshold(threshold=0.1)和selector = VarianceThreshold()输出的结果不一样

### Describe the bug

import numpy as np
X = np.arange(30,dtype=float).reshape((10, 3))
X[:,1] = 1
from sklearn.feature_selection import VarianceThreshold
vt = VarianceThreshold(threshold=0.01)
xt = vt.fit_transform(X)
# 未设置阈值时，可能未实际计算方差
vt1 = VarianceThreshold()
vt1.fit(X)                # 先调用fit方法
print(vt1.variances_)     # 现在可以安全访问

# 设置阈值后强制计算
vt2 = VarianceThreshold(threshold=0.01)
vt2.fit(X)  # 实际执行计算
print(vt2.variances_)     # 输出正确值
vt = VarianceThreshold(threshold=0.01)
vt.fit(X)  # 确保实际计算
print(vt.variances_)
# 检查方差计算一致性
manual_var = np.var(X, axis=0, ddof=0)
sklearn_var = vt.variances_
if not np.allclose(manual_var, sklearn_var):
    print(f"警告：方差计算不一致！手动:{manual_var}，sklearn:{sklearn_var}")
    # 确保使用最新稳定版
import sklearn
print("scikit-learn版本:", sklearn.__version__)  # 应 ≥ 1.0

[27.  0. 27.]
[74.25  0.   74.25]
[74.25  0.   74.25]
scikit-learn版本: 1.7.0

### Steps/Code to Reproduce

[27.  0. 27.]
[74.25  0.   74.25]
[74.25  0.   74.25]
scikit-learn版本: 1.7.0

### Expected Results

[27.  0. 27.]
[74.25  0.   74.25]
[74.25  0.   74.25]
scikit-learn版本: 1.7.0

### Actual Results

[27.  0. 27.]
[74.25  0.   74.25]
[74.25  0.   74.25]
scikit-learn版本: 1.7.0

### Versions

```shell
System:
    python: 3.12.1 (tags/v3.12.1:2305ca5, Dec  7 2023, 22:03:25) [MSC v.1937 64 bit (AMD64)]
executable: c:\Users\wp\Desktop\python312\python.exe
   machine: Windows-10-10.0.19045-SP0

Python dependencies:
      sklearn: 1.7.0
          pip: 25.1.1
   setuptools: 78.1.0
        numpy: 1.26.0
        scipy: 1.13.1
       Cython: None
       pandas: 2.2.3
   matplotlib: 3.10.1
       joblib: 1.4.2
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 4
         prefix: libopenblas
...
       filepath: C:\Users\wp\Desktop\python312\Lib\site-packages\scipy.libs\libopenblas_v0.3.27--3aa239bc726cfb0bd8e5330d8d4c15c6.dll
        version: 0.3.27
threading_layer: pthreads
   architecture: Haswell
```

COMMENT:
> why vt1 = VarianceThreshold（）and vt2 = VarianceThreshold（threshold=0.01）output different

Because by default `threshold=0.0` so the behaviour is expected to be different.

Labels: Bug, Needs Triage
RFC: stop using scikit-learn `stable_cumsum` and instead use `np.cumsum/xp.cumulative_sum` directly

As discussed in https://github.com/scikit-learn/scikit-learn/pull/30878/files#r2142562746, our current `stable_cumsum` function brings very little value to the user: it does extra computation to check that `np.allclose(np.sum(x), np.cumsum(x)[-1])` and raises a warning otherwise. However, in most cases, users can do nothing about the warning.

Furthermore, as seen in the CI of #30878, the array API compatible libraries we test against do not have the same numerical stability behavior for `sum` and `cumsum`, so it makes it challenging to write a test for the occurrence of this warning that is consistent across libraries.

So I would rather not waste the overhead of computing `np.sum(x)` and just always directly call `np.cumsum` or `xp.cumsum` and deprecate `sklearn.utils.extmath.stable_cumsum`.

COMMENT:
If I remember correctly, I think this one of the reasons why our kmeans++ implementation is slower than alternative implementations in other libraries such as Intel oneDAL.

Labels: RFC, Array API
RFC: stop using scikit-learn `stable_cumsum` and instead use `np.cumsum/xp.cumulative_sum` directly

As discussed in https://github.com/scikit-learn/scikit-learn/pull/30878/files#r2142562746, our current `stable_cumsum` function brings very little value to the user: it does extra computation to check that `np.allclose(np.sum(x), np.cumsum(x)[-1])` and raises a warning otherwise. However, in most cases, users can do nothing about the warning.

Furthermore, as seen in the CI of #30878, the array API compatible libraries we test against do not have the same numerical stability behavior for `sum` and `cumsum`, so it makes it challenging to write a test for the occurrence of this warning that is consistent across libraries.

So I would rather not waste the overhead of computing `np.sum(x)` and just always directly call `np.cumsum` or `xp.cumsum` and deprecate `sklearn.utils.extmath.stable_cumsum`.

COMMENT:
I agree with this proposal. Thanks @ogrisel

Labels: RFC, Array API
RFC: stop using scikit-learn `stable_cumsum` and instead use `np.cumsum/xp.cumulative_sum` directly

As discussed in https://github.com/scikit-learn/scikit-learn/pull/30878/files#r2142562746, our current `stable_cumsum` function brings very little value to the user: it does extra computation to check that `np.allclose(np.sum(x), np.cumsum(x)[-1])` and raises a warning otherwise. However, in most cases, users can do nothing about the warning.

Furthermore, as seen in the CI of #30878, the array API compatible libraries we test against do not have the same numerical stability behavior for `sum` and `cumsum`, so it makes it challenging to write a test for the occurrence of this warning that is consistent across libraries.

So I would rather not waste the overhead of computing `np.sum(x)` and just always directly call `np.cumsum` or `xp.cumsum` and deprecate `sklearn.utils.extmath.stable_cumsum`.

COMMENT:
`stable_cumsum` also makes sure that the cumsum computation is done with float64, i.e. `np.cumsum(..., dtype=np.float64)`. What would the plan be on this aspect?

Doing a bit of archeology the original motivation for `stable_cumsum` was that `roc_auc_score` could give "wrong" results with float32 weights, see https://github.com/scikit-learn/scikit-learn/issues/6842.

I tried quickly removing `stable_cumsum` in `sklearn.metrics._ranking._binary_clf_curve` (see diff below) and I can reproduce the problematic behaviour locally:

```py
from sklearn.metrics import roc_auc_score
import numpy as np

rng = np.random.RandomState(42)
n_samples = 4 * 10 ** 7
y = rng.randint(2, size=n_samples)
prediction = rng.normal(size=n_samples) + y * 0.01
trivial_weight = np.ones(n_samples)
print('without weights', roc_auc_score(y, prediction))
print('float32 weights', roc_auc_score(y, prediction, sample_weight=trivial_weight.astype('float32')))
print('float64 weights', roc_auc_score(y, prediction, sample_weight=trivial_weight.astype('float64')))
```

```
without weights 0.5027392452566966
float32 weights 0.5835567712783813
float64 weights 0.5027392452566966
```

```diff
diff --git a/sklearn/metrics/_ranking.py b/sklearn/metrics/_ranking.py
index 2d0e5211c2..802279a812 100644
--- a/sklearn/metrics/_ranking.py
+++ b/sklearn/metrics/_ranking.py
@@ -898,11 +898,11 @@ def _binary_clf_curve(y_true, y_score, pos_label=None, sample_weight=None):
     threshold_idxs = np.r_[distinct_value_indices, y_true.size - 1]
 
     # accumulate the true positives with decreasing threshold
-    tps = stable_cumsum(y_true * weight)[threshold_idxs]
+    tps = np.cumsum(y_true * weight)[threshold_idxs]
     if sample_weight is not None:
         # express fps as a cumsum to ensure fps is increasing even in
         # the presence of floating point errors
-        fps = stable_cumsum((1 - y_true) * weight)[threshold_idxs]
+        fps = np.cumsum((1 - y_true) * weight)[threshold_idxs]
     else:
         fps = 1 + threshold_idxs - tps
     return fps, tps, y_score[threshold_idxs]
```

Labels: RFC, Array API
RFC: stop using scikit-learn `stable_cumsum` and instead use `np.cumsum/xp.cumulative_sum` directly

As discussed in https://github.com/scikit-learn/scikit-learn/pull/30878/files#r2142562746, our current `stable_cumsum` function brings very little value to the user: it does extra computation to check that `np.allclose(np.sum(x), np.cumsum(x)[-1])` and raises a warning otherwise. However, in most cases, users can do nothing about the warning.

Furthermore, as seen in the CI of #30878, the array API compatible libraries we test against do not have the same numerical stability behavior for `sum` and `cumsum`, so it makes it challenging to write a test for the occurrence of this warning that is consistent across libraries.

So I would rather not waste the overhead of computing `np.sum(x)` and just always directly call `np.cumsum` or `xp.cumsum` and deprecate `sklearn.utils.extmath.stable_cumsum`.

COMMENT:
I think we could just use xp.cumulative_sum with the max float dtype supported where ever this function is being used. https://data-apis.org/array-api/latest/API_specification/generated/array_api.cumulative_sum.html#array_api.cumulative_sum

So the main part that would be removed is the warning related code.

Labels: RFC, Array API
RFC: stop using scikit-learn `stable_cumsum` and instead use `np.cumsum/xp.cumulative_sum` directly

As discussed in https://github.com/scikit-learn/scikit-learn/pull/30878/files#r2142562746, our current `stable_cumsum` function brings very little value to the user: it does extra computation to check that `np.allclose(np.sum(x), np.cumsum(x)[-1])` and raises a warning otherwise. However, in most cases, users can do nothing about the warning.

Furthermore, as seen in the CI of #30878, the array API compatible libraries we test against do not have the same numerical stability behavior for `sum` and `cumsum`, so it makes it challenging to write a test for the occurrence of this warning that is consistent across libraries.

So I would rather not waste the overhead of computing `np.sum(x)` and just always directly call `np.cumsum` or `xp.cumsum` and deprecate `sklearn.utils.extmath.stable_cumsum`.

COMMENT:
+1 for explicit casting to max float dtype in functions where there is a proven case that we need it.

But I would rather not case when we don't need it (in particular, I suspect this is not needed in k-means++).

Labels: RFC, Array API
RFC: stop using scikit-learn `stable_cumsum` and instead use `np.cumsum/xp.cumulative_sum` directly

As discussed in https://github.com/scikit-learn/scikit-learn/pull/30878/files#r2142562746, our current `stable_cumsum` function brings very little value to the user: it does extra computation to check that `np.allclose(np.sum(x), np.cumsum(x)[-1])` and raises a warning otherwise. However, in most cases, users can do nothing about the warning.

Furthermore, as seen in the CI of #30878, the array API compatible libraries we test against do not have the same numerical stability behavior for `sum` and `cumsum`, so it makes it challenging to write a test for the occurrence of this warning that is consistent across libraries.

So I would rather not waste the overhead of computing `np.sum(x)` and just always directly call `np.cumsum` or `xp.cumsum` and deprecate `sklearn.utils.extmath.stable_cumsum`.

COMMENT:
+1 to remove `stable_cumsum` and cast wherever needed.

Labels: RFC, Array API
RFC: stop using scikit-learn `stable_cumsum` and instead use `np.cumsum/xp.cumulative_sum` directly

As discussed in https://github.com/scikit-learn/scikit-learn/pull/30878/files#r2142562746, our current `stable_cumsum` function brings very little value to the user: it does extra computation to check that `np.allclose(np.sum(x), np.cumsum(x)[-1])` and raises a warning otherwise. However, in most cases, users can do nothing about the warning.

Furthermore, as seen in the CI of #30878, the array API compatible libraries we test against do not have the same numerical stability behavior for `sum` and `cumsum`, so it makes it challenging to write a test for the occurrence of this warning that is consistent across libraries.

So I would rather not waste the overhead of computing `np.sum(x)` and just always directly call `np.cumsum` or `xp.cumsum` and deprecate `sklearn.utils.extmath.stable_cumsum`.

COMMENT:
+1 to remove `stable_cumsum` and cast.

Labels: RFC, Array API
RFC: stop using scikit-learn `stable_cumsum` and instead use `np.cumsum/xp.cumulative_sum` directly

As discussed in https://github.com/scikit-learn/scikit-learn/pull/30878/files#r2142562746, our current `stable_cumsum` function brings very little value to the user: it does extra computation to check that `np.allclose(np.sum(x), np.cumsum(x)[-1])` and raises a warning otherwise. However, in most cases, users can do nothing about the warning.

Furthermore, as seen in the CI of #30878, the array API compatible libraries we test against do not have the same numerical stability behavior for `sum` and `cumsum`, so it makes it challenging to write a test for the occurrence of this warning that is consistent across libraries.

So I would rather not waste the overhead of computing `np.sum(x)` and just always directly call `np.cumsum` or `xp.cumsum` and deprecate `sklearn.utils.extmath.stable_cumsum`.

COMMENT:
I removed the "Needs Decision" label because we seem to have reached a consensus. Thanks, @lesteve, for the archeological work.

Labels: RFC, Array API
⚠️ CI failed on Wheel builder (last failure: Jun 12, 2025) ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/15601223966)** (Jun 12, 2025)

COMMENT:
The free-threaded failures are likely due to cibuildwheel 3.0.0 release, from [changelog](https://cibuildwheel.pypa.io/en/stable/changelog/#v300):

> Removed the CIBW_PRERELEASE_PYTHONS and CIBW_FREE_THREADED_SUPPORT options - these have been folded into the [enable](https://cibuildwheel.pypa.io/en/stable/options/#enable) option instead. (#2095)

See https://github.com/pypa/cibuildwheel/pull/2095 for more details.

Labels: Needs Triage
TarFile.extractall() got an unexpected keyword argument 'filter'

### Describe the bug

For the latest version `1.7.0`, it can be installed with Python 3.10, but the parameter `filter` is available starting from Python 3.12 (See: https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall ). 
https://github.com/scikit-learn/scikit-learn/blob/5194440b5d41e73ff436c45e35aa1476223f753c/sklearn/datasets/_twenty_newsgroups.py#L87

As a result, when I attempted to download the `20newsgroups` dataset, an error occurred:

```
  File "\xxx\sklearn\utils\_param_validation.py", line 218, in wrapper
    return func(*args, **kwargs)
  File "\xxx\sklearn\datasets\_twenty_newsgroups.py", line 322, in fetch_20newsgroups
    cache = _download_20newsgroups(
  File "\xxx\sklearn\datasets\_twenty_newsgroups.py", line 87, in _download_20newsgroups
    fp.extractall(path=target_dir, filter="data")
TypeError: TarFile.extractall() got an unexpected keyword argument 'filter'
```

### Steps/Code to Reproduce

```
from sklearn.datasets import fetch_20newsgroups
cats = ['alt.atheism', 'sci.space']
newsgroups_train = fetch_20newsgroups(subset='train', categories=cats)
```

### Expected Results

```
list(newsgroups_train.target_names)
newsgroups_train.filenames.shape
newsgroups_train.target.shape
newsgroups_train.target[:10]>>> cats = ['alt.atheism', 'sci.space']
```

### Actual Results

```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "\xxx\sklearn\utils\_param_validation.py", line 218, in wrapper
    return func(*args, **kwargs)
  File "\xxx\sklearn\datasets\_twenty_newsgroups.py", line 322, in fetch_20newsgroups
    cache = _download_20newsgroups(
  File "\xxx\sklearn\datasets\_twenty_newsgroups.py", line 87, in _download_20newsgroups
    fp.extractall(path=target_dir, filter="data")
TypeError: TarFile.extractall() got an unexpected keyword argument 'filter'
```

### Versions

```shell
`1.7.0`
```

COMMENT:
Thanks for the issue! We should indeed fix this:
- revert the relevant part of https://github.com/scikit-learn/scikit-learn/pull/31022
- mention that we can drop `sklearn.utils.fixes.tarfile_extractall` when our minimum supported version is Python 3.12 is the first version that has the `filter` from the start i.e. 3.12.0.

For completeness, the doc is slightly misleading: if you are using Python 3.10.x with `x>=12`, Python 3.11.x with `x>=4` or Python>=3.12 you are fine. This is based on the [3.10 doc](https://docs.python.org/3.10/library/tarfile.html#tarfile.TarFile.extractall) that says
> Changed in version 3.10.12: Added the filter parameter

and the [3.11 doc](https://docs.python.org/3.11/library/tarfile.html#tarfile.TarFile.extractall) says
> Changed in version 3.11.4: Added the filter parameter.

Labels: Bug, Regression
32-Bit Raspberry Pi OS Installation Issues with UV

### Describe the bug

When attempting to install scikit-learn==1.4.2 - 1.6.1 on Raspberry Pi OS Lite 32-Bit (Bookworm) or Raspberry Pi OS Lit 32-Bit (Bullseye) with UV, the following error is given:
```
  × Failed to download and build `scikit-learn==1.4.2`
  ├─▶ Failed to resolve requirements from `build-system.requires`
  ├─▶ No solution found when resolving: `setuptools`, `wheel`, `cython>=3.0.8`, `numpy==2.0.0rc1`, `scipy>=1.6.0`
  ╰─▶ Because there is no version of numpy==2.0.0rc1 and you require numpy==2.0.0rc1, we can conclude that your
      requirements are unsatisfiable.
```

If I had to guess, it's that the numpy==2.0.0rc1 is the issue, but I'm not sure.  

Bullseye is also on Python 3.9 so the last version we can install is v1.6.1.  



### Steps/Code to Reproduce

```bash
# 1. Install UV
# 2. Create Virtual Environment
uv venv --system-site-packages test 
# 3. Start venv
source test/bin/activate
# 4. Install scikit-learn
uv pip install scikit-learn==1.6.1
```

### Expected Results

Expect that it should install correctly without errors. 

### Actual Results

```
  × Failed to download and build `scikit-learn==1.4.2`
  ├─▶ Failed to resolve requirements from `build-system.requires`
  ├─▶ No solution found when resolving: `setuptools`, `wheel`, `cython>=3.0.8`, `numpy==2.0.0rc1`, `scipy>=1.6.0`
  ╰─▶ Because there is no version of numpy==2.0.0rc1 and you require numpy==2.0.0rc1, we can conclude that your
      requirements are unsatisfiable.
```

### Versions

```shell
1.4.2
1.6.0
1.6.1
```

COMMENT:
Some suggestions:
- for scikit-learn 1.4.2 and the `numpy==2.0.0rc1` it seems like `uv` has a prerelease handling that you may want to look at https://docs.astral.sh/uv/reference/cli/#uv-run--prerelease
- I am guessing the error with scikit-learn 1.6.1 is different, could you post it as well for further reference?
- could you try with `pip` to see whether the same problem happens?

I am going to close this one as I feel this is quite unlikely to be an issue in scikit-learn. In case further investigation shows that I am wrong, feel free to reopen!

Labels: Bug, Needs Investigation
32-Bit Raspberry Pi OS Installation Issues with UV

### Describe the bug

When attempting to install scikit-learn==1.4.2 - 1.6.1 on Raspberry Pi OS Lite 32-Bit (Bookworm) or Raspberry Pi OS Lit 32-Bit (Bullseye) with UV, the following error is given:
```
  × Failed to download and build `scikit-learn==1.4.2`
  ├─▶ Failed to resolve requirements from `build-system.requires`
  ├─▶ No solution found when resolving: `setuptools`, `wheel`, `cython>=3.0.8`, `numpy==2.0.0rc1`, `scipy>=1.6.0`
  ╰─▶ Because there is no version of numpy==2.0.0rc1 and you require numpy==2.0.0rc1, we can conclude that your
      requirements are unsatisfiable.
```

If I had to guess, it's that the numpy==2.0.0rc1 is the issue, but I'm not sure.  

Bullseye is also on Python 3.9 so the last version we can install is v1.6.1.  



### Steps/Code to Reproduce

```bash
# 1. Install UV
# 2. Create Virtual Environment
uv venv --system-site-packages test 
# 3. Start venv
source test/bin/activate
# 4. Install scikit-learn
uv pip install scikit-learn==1.6.1
```

### Expected Results

Expect that it should install correctly without errors. 

### Actual Results

```
  × Failed to download and build `scikit-learn==1.4.2`
  ├─▶ Failed to resolve requirements from `build-system.requires`
  ├─▶ No solution found when resolving: `setuptools`, `wheel`, `cython>=3.0.8`, `numpy==2.0.0rc1`, `scipy>=1.6.0`
  ╰─▶ Because there is no version of numpy==2.0.0rc1 and you require numpy==2.0.0rc1, we can conclude that your
      requirements are unsatisfiable.
```

### Versions

```shell
1.4.2
1.6.0
1.6.1
```

COMMENT:
Actually looks like there is no `numpy==2.0.0rc1` on PyPI. I guess it was removed somehow, this is quite unexpected 🤔 ... probably this numpy mailing list [thread](https://mail.python.org/archives/list/numpy-discussion@python.org/thread/MOIRY73LIHSQTEWDBRYGNU6767NZC2HG/#H7BQQGWC3QY5SYQJRZW74KSGF4KSIXRJ) is related ...

I guess to have something that works I would suggest trying with scikit-learn 1.6.1.

Labels: Bug, Needs Investigation
32-Bit Raspberry Pi OS Installation Issues with UV

### Describe the bug

When attempting to install scikit-learn==1.4.2 - 1.6.1 on Raspberry Pi OS Lite 32-Bit (Bookworm) or Raspberry Pi OS Lit 32-Bit (Bullseye) with UV, the following error is given:
```
  × Failed to download and build `scikit-learn==1.4.2`
  ├─▶ Failed to resolve requirements from `build-system.requires`
  ├─▶ No solution found when resolving: `setuptools`, `wheel`, `cython>=3.0.8`, `numpy==2.0.0rc1`, `scipy>=1.6.0`
  ╰─▶ Because there is no version of numpy==2.0.0rc1 and you require numpy==2.0.0rc1, we can conclude that your
      requirements are unsatisfiable.
```

If I had to guess, it's that the numpy==2.0.0rc1 is the issue, but I'm not sure.  

Bullseye is also on Python 3.9 so the last version we can install is v1.6.1.  



### Steps/Code to Reproduce

```bash
# 1. Install UV
# 2. Create Virtual Environment
uv venv --system-site-packages test 
# 3. Start venv
source test/bin/activate
# 4. Install scikit-learn
uv pip install scikit-learn==1.6.1
```

### Expected Results

Expect that it should install correctly without errors. 

### Actual Results

```
  × Failed to download and build `scikit-learn==1.4.2`
  ├─▶ Failed to resolve requirements from `build-system.requires`
  ├─▶ No solution found when resolving: `setuptools`, `wheel`, `cython>=3.0.8`, `numpy==2.0.0rc1`, `scipy>=1.6.0`
  ╰─▶ Because there is no version of numpy==2.0.0rc1 and you require numpy==2.0.0rc1, we can conclude that your
      requirements are unsatisfiable.
```

### Versions

```shell
1.4.2
1.6.0
1.6.1
```

COMMENT:
You're correct!  The 1.6.1 version has a different issue.  It appears with further investigation that UV will try to build numpy in this version, but after several hours, will run out of space and error out.  

Running on Raspberry Pi OS 12 Bookworm 32-Bit with Python 3.11.  

So perhaps it's just that building numpy is too much for the Raspberry Pi 3b+.

Labels: Bug, Needs Investigation