Talip7/scikit-learn-issues-multilabel huggingface dataset:
Add new feature to use only a sample of training data in KNNImputer

### Describe the workflow you want to enable

I would like the team to add an argument(s) for using only part of the entire dataset to train the KNNImputer.

### Describe your proposed solution

This will require adding new argument(s) to the KNNImputer that allows the user to train the imputer with only part of the training data. This will save a significant amount of time as the current version takes too long and is almost not usable for fairly large training data.

The proposed solution runs orders of magnitude faster than using the whole dataset and may give higher accuracy than using constant imputation.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

imputer = KNNImputer()
imputer.fit(df)
df_new = imputer.transform(df) # This takes a very long time if dataset is fairly large

### What the proposed solution may look like
imputer = KNNImputer(sample=1000, random_state=None)
imputer.fit(df) # Uses only a thousand samples to train the imputer
df_new = imputer.transform(df) # Runs orders of magnitude faster than using the whole dataset.

COMMENT:
@thomasjpfan Please take a look at the [QuantileTransformer](https://scikit-learn.org/stable/modules/generated/sklearn.preprocessing.QuantileTransformer.html#sklearn.preprocessing.QuantileTransformer) subsample argument. The idea is the same, it just makes sense to not use all data in order to improve the efficiency of the module.

Labels: New Feature, module:impute
Add new feature to use only a sample of training data in KNNImputer

### Describe the workflow you want to enable

I would like the team to add an argument(s) for using only part of the entire dataset to train the KNNImputer.

### Describe your proposed solution

This will require adding new argument(s) to the KNNImputer that allows the user to train the imputer with only part of the training data. This will save a significant amount of time as the current version takes too long and is almost not usable for fairly large training data.

The proposed solution runs orders of magnitude faster than using the whole dataset and may give higher accuracy than using constant imputation.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

imputer = KNNImputer()
imputer.fit(df)
df_new = imputer.transform(df) # This takes a very long time if dataset is fairly large

### What the proposed solution may look like
imputer = KNNImputer(sample=1000, random_state=None)
imputer.fit(df) # Uses only a thousand samples to train the imputer
df_new = imputer.transform(df) # Runs orders of magnitude faster than using the whole dataset.

COMMENT:
There are many algorithms that can take advantage of subsampling. With that in mind, new features still need to meet scikit-learn's [inclusion criterion](https://scikit-learn.org/stable/faq.html#what-are-the-inclusion-criteria-for-new-algorithms) because every new feature increases the maintenance cost.

In this case, one needs to showcase the benefit of subsampling by having reproducible benchmarks or referencing papers that have already done this work.

Labels: New Feature, module:impute
Add new feature to use only a sample of training data in KNNImputer

### Describe the workflow you want to enable

I would like the team to add an argument(s) for using only part of the entire dataset to train the KNNImputer.

### Describe your proposed solution

This will require adding new argument(s) to the KNNImputer that allows the user to train the imputer with only part of the training data. This will save a significant amount of time as the current version takes too long and is almost not usable for fairly large training data.

The proposed solution runs orders of magnitude faster than using the whole dataset and may give higher accuracy than using constant imputation.

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

imputer = KNNImputer()
imputer.fit(df)
df_new = imputer.transform(df) # This takes a very long time if dataset is fairly large

### What the proposed solution may look like
imputer = KNNImputer(sample=1000, random_state=None)
imputer.fit(df) # Uses only a thousand samples to train the imputer
df_new = imputer.transform(df) # Runs orders of magnitude faster than using the whole dataset.

COMMENT:
@thomasjpfan The first option looks quite promising. It should be possible to show how subsampling affect the accuracy and efficiency of the imputation.

Thanks for the further clarification

Labels: New Feature, module:impute
Second build failure for s390x and ppc64

### Describe the bug

Hi,
besides issue #22503 I've observed an _additional_ error in the test suite for the architectures s390x and ppc64.

### Steps/Code to Reproduce

```
pytest -m "not network" -v --color=no -k "not test_load_boston_alternative and not test_dump"
```
You can find a [full build log for arm64](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=s390x&ver=1.0.2-1&stamp=1644952396&raw=0) where you can seek for the string above to see the start of the test procedure.

### Expected Results

Passing the test suite without any error.

### Actual Results

    ___________ [doctest] sklearn.feature_extraction._hash.FeatureHasher ___________
    081     DictVectorizer : Vectorizes string-valued features using a hash table.
    082     sklearn.preprocessing.OneHotEncoder : Handles nominal/categorical features.
    083
    084     Examples
    085     --------
    086     >>> from sklearn.feature_extraction import FeatureHasher
    087     >>> h = FeatureHasher(n_features=10)
    088     >>> D = [{'dog': 1, 'cat':2, 'elephant':4},{'dog': 2, 'run': 5}]
    089     >>> f = h.transform(D)
    090     >>> f.toarray()
    Expected:
        array([[ 0.,  0., -4., -1.,  0.,  0.,  0.,  0.,  0.,  2.],
               [ 0.,  0.,  0., -2., -5.,  0.,  0.,  0.,  0.,  0.]])
    Got:
        array([[ 0.,  0.,  0., -1.,  0.,  0.,  0.,  4.,  0.,  2.],
               [ 0.,  0.,  0., -2., -5.,  0.,  0.,  0.,  0.,  0.]])

    /<<PKGBUILDDIR>>/.pybuild/cpython3_3.9/build/sklearn/feature_extraction/_hash.py:90: DocTestFailure
    = 2 failed, 22017 passed, 404 skipped, 3 deselected, 59 xfailed, 38 xpassed, 2351 warnings in 686.07s (0:11:26) =


### Versions

```shell
`1.0.2`

Also see the [full build log](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=s390x&ver=1.0.2-1&stamp=1644952396&raw=0) what other components are used.
```

COMMENT:
I can confirm that I am seeing this replicated on s390x when I attempt local builds of SciPy 1.10 and 1.11 on RHEL 9.

Labels: Bug, module:feature_extraction, Needs Investigation
AdaBoostRegressor doctest failure for arm64, ppc64el, s390x, ppc64 and risc64

### Describe the bug

Hi,
I've just uploaded version 1.0.2 to Debian unstable.  In Debian we have an autobuilder infrastructure where code is compiled for several architectures. The code builds fine and passes the test suite for amd64, i386 and may be less interesting but luckily for the architectures hppa and m68k.  However on the architectures arm64, ppc64el, s390x, ppc64 and risc64 there is a single error in the test suite.  If you are interested you can checkout all [autobuilder results](https://buildd.debian.org/status/package.php?p=scikit-learn)

### Steps/Code to Reproduce

```
pytest -m "not network" -v --color=no -k "not test_load_boston_alternative and not test_dump"
```
You can find a [full build log for s390x](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=arm64&ver=1.0.2-1&stamp=1644956264&raw=0) where you can seek for the string above to see the start of the test procedure.

### Expected Results

Passing the test suite without any error.

### Actual Results

    =================================== FAILURES ===================================
    ________ [doctest] sklearn.ensemble._weight_boosting.AdaBoostRegressor _________
    1004     Examples
    1005     --------
    1006     >>> from sklearn.ensemble import AdaBoostRegressor
    1007     >>> from sklearn.datasets import make_regression
    1008     >>> X, y = make_regression(n_features=4, n_informative=2,
    1009     ...                        random_state=0, shuffle=False)
    1010     >>> regr = AdaBoostRegressor(random_state=0, n_estimators=100)
    1011     >>> regr.fit(X, y)
    1012     AdaBoostRegressor(n_estimators=100, random_state=0)
    1013     >>> regr.predict([[0, 0, 0, 0]])
    Expected:
        array([4.7972...])
    Got:
        array([5.74049295])

    /<<PKGBUILDDIR>>/.pybuild/cpython3_3.9/build/sklearn/ensemble/_weight_boosting.py:1013: DocTestFailure
    = 1 failed, 22012 passed, 404 skipped, 7 deselected, 59 xfailed, 40 xpassed, 2350 warnings in 2090.20s (0:34:50) =


### Versions

`1.0.2`

Also see the [full build log](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=arm64&ver=1.0.2-1&stamp=1644956264&raw=0) what other components are used.

COMMENT:
I wonder if Adaboost does not have some fundamental numerical stability problems. We would probably need to have a look at the magnitude of the weights at each iteration on this dataset to see what's going on.

While probably not directly related, we already observed unexpected behaviors when the number of iterations increases in #20443.

Labels: Bug, module:ensemble, Needs Investigation
AdaBoostRegressor doctest failure for arm64, ppc64el, s390x, ppc64 and risc64

### Describe the bug

Hi,
I've just uploaded version 1.0.2 to Debian unstable.  In Debian we have an autobuilder infrastructure where code is compiled for several architectures. The code builds fine and passes the test suite for amd64, i386 and may be less interesting but luckily for the architectures hppa and m68k.  However on the architectures arm64, ppc64el, s390x, ppc64 and risc64 there is a single error in the test suite.  If you are interested you can checkout all [autobuilder results](https://buildd.debian.org/status/package.php?p=scikit-learn)

### Steps/Code to Reproduce

```
pytest -m "not network" -v --color=no -k "not test_load_boston_alternative and not test_dump"
```
You can find a [full build log for s390x](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=arm64&ver=1.0.2-1&stamp=1644956264&raw=0) where you can seek for the string above to see the start of the test procedure.

### Expected Results

Passing the test suite without any error.

### Actual Results

    =================================== FAILURES ===================================
    ________ [doctest] sklearn.ensemble._weight_boosting.AdaBoostRegressor _________
    1004     Examples
    1005     --------
    1006     >>> from sklearn.ensemble import AdaBoostRegressor
    1007     >>> from sklearn.datasets import make_regression
    1008     >>> X, y = make_regression(n_features=4, n_informative=2,
    1009     ...                        random_state=0, shuffle=False)
    1010     >>> regr = AdaBoostRegressor(random_state=0, n_estimators=100)
    1011     >>> regr.fit(X, y)
    1012     AdaBoostRegressor(n_estimators=100, random_state=0)
    1013     >>> regr.predict([[0, 0, 0, 0]])
    Expected:
        array([4.7972...])
    Got:
        array([5.74049295])

    /<<PKGBUILDDIR>>/.pybuild/cpython3_3.9/build/sklearn/ensemble/_weight_boosting.py:1013: DocTestFailure
    = 1 failed, 22012 passed, 404 skipped, 7 deselected, 59 xfailed, 40 xpassed, 2350 warnings in 2090.20s (0:34:50) =


### Versions

`1.0.2`

Also see the [full build log](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=arm64&ver=1.0.2-1&stamp=1644956264&raw=0) what other components are used.

COMMENT:
Please note:  I mentioned in #23901 arm64 and ppc64el explicitly since the failure messages are identical.  There are failures on other architectures like [s390x](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=s390x&ver=1.1.1-1&stamp=1653336896&raw=0), [armel](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=armel&ver=1.1.1-1&stamp=1653343638&raw=0) or [armhf](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=armhf&ver=1.1.1-1&stamp=1653339912&raw=0) (the 32 bit arm architectures are running into Bus errors).

Labels: Bug, module:ensemble, Needs Investigation
AdaBoostRegressor doctest failure for arm64, ppc64el, s390x, ppc64 and risc64

### Describe the bug

Hi,
I've just uploaded version 1.0.2 to Debian unstable.  In Debian we have an autobuilder infrastructure where code is compiled for several architectures. The code builds fine and passes the test suite for amd64, i386 and may be less interesting but luckily for the architectures hppa and m68k.  However on the architectures arm64, ppc64el, s390x, ppc64 and risc64 there is a single error in the test suite.  If you are interested you can checkout all [autobuilder results](https://buildd.debian.org/status/package.php?p=scikit-learn)

### Steps/Code to Reproduce

```
pytest -m "not network" -v --color=no -k "not test_load_boston_alternative and not test_dump"
```
You can find a [full build log for s390x](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=arm64&ver=1.0.2-1&stamp=1644956264&raw=0) where you can seek for the string above to see the start of the test procedure.

### Expected Results

Passing the test suite without any error.

### Actual Results

    =================================== FAILURES ===================================
    ________ [doctest] sklearn.ensemble._weight_boosting.AdaBoostRegressor _________
    1004     Examples
    1005     --------
    1006     >>> from sklearn.ensemble import AdaBoostRegressor
    1007     >>> from sklearn.datasets import make_regression
    1008     >>> X, y = make_regression(n_features=4, n_informative=2,
    1009     ...                        random_state=0, shuffle=False)
    1010     >>> regr = AdaBoostRegressor(random_state=0, n_estimators=100)
    1011     >>> regr.fit(X, y)
    1012     AdaBoostRegressor(n_estimators=100, random_state=0)
    1013     >>> regr.predict([[0, 0, 0, 0]])
    Expected:
        array([4.7972...])
    Got:
        array([5.74049295])

    /<<PKGBUILDDIR>>/.pybuild/cpython3_3.9/build/sklearn/ensemble/_weight_boosting.py:1013: DocTestFailure
    = 1 failed, 22012 passed, 404 skipped, 7 deselected, 59 xfailed, 40 xpassed, 2350 warnings in 2090.20s (0:34:50) =


### Versions

`1.0.2`

Also see the [full build log](https://buildd.debian.org/status/fetch.php?pkg=scikit-learn&arch=arm64&ver=1.0.2-1&stamp=1644956264&raw=0) what other components are used.

COMMENT:
I'm closing this issue in favor of https://github.com/scikit-learn/scikit-learn/issues/23901 as it targets the latest version. This is because we will not be releasing a bug fix for `1.0.X`.

The bus error in armel and armhf is a separate issue and not related to `AdaBoostRegressor`. This should have it's own issue.

Labels: Bug, module:ensemble, Needs Investigation
Document "neg_root_mean_squared_error" in the "scoring" parameter

### Describe the workflow you want to enable

I would like users to be able to do:
```
cross_val_score(estimator, X, y, scroring="neg_root_mean_squared_error")
```
This is currently possible by specifying "neg_mean_squared_error" and taking the squared root (negating the sign). 

I would like to make this easier, because I think that the RMSE should be used more, as it gives a result in the same units as the units of y (for instance dollars if y is in dollars).

### Describe your proposed solution

Add a scorer that use mean_squared_error(..., squared=False) to the SCORERS dict in sklearn/metrics/_scorer.py, and update the docs (for instance in doc/modules/model_evaluation.rst, but I would inspect the different files where neg_mean_squared_error appears (for instance, found by "git grep neg_mean_squared_error") and consider on a case by case if the new function should be applied.

### Describe alternatives you've considered, if relevant

Specifying "neg_mean_squared_error" and taking the squared root (negating the sign)

### Additional context

_No response_

COMMENT:
It is already exposed at least in `main`

```python
In [1]: from sklearn.linear_model import Ridge
   ...: import numpy as np
   ...: n_samples, n_features = 10, 5
   ...: rng = np.random.RandomState(0)
   ...: y = rng.randn(n_samples)
   ...: X = rng.randn(n_samples, n_features)
   ...: clf = Ridge(alpha=1.0)

In [2]: from sklearn.model_selection import cross_val_score

In [5]: cross_val_score(clf, X, y, scoring="neg_root_mean_squared_error")
Out[5]: array([-0.98616884, -0.93935052, -2.13284822, -0.4962979 , -0.79003764])
```

Labels: New Feature, Documentation, Moderate, module:metrics, Breaking Change, Needs Triage
Document "neg_root_mean_squared_error" in the "scoring" parameter

### Describe the workflow you want to enable

I would like users to be able to do:
```
cross_val_score(estimator, X, y, scroring="neg_root_mean_squared_error")
```
This is currently possible by specifying "neg_mean_squared_error" and taking the squared root (negating the sign). 

I would like to make this easier, because I think that the RMSE should be used more, as it gives a result in the same units as the units of y (for instance dollars if y is in dollars).

### Describe your proposed solution

Add a scorer that use mean_squared_error(..., squared=False) to the SCORERS dict in sklearn/metrics/_scorer.py, and update the docs (for instance in doc/modules/model_evaluation.rst, but I would inspect the different files where neg_mean_squared_error appears (for instance, found by "git grep neg_mean_squared_error") and consider on a case by case if the new function should be applied.

### Describe alternatives you've considered, if relevant

Specifying "neg_mean_squared_error" and taking the squared root (negating the sign)

### Additional context

_No response_

COMMENT:
One problem that I spot with the metric is that it is only listed once without explanation and used in one example.

It could be worth improving our documentation in the MSE section to point out this parameter and why RMSE is used.
@GaelVaroquaux Do you want to reopen the issue and repurpose it to a documentation improvement?

Labels: New Feature, Documentation, Moderate, module:metrics, Breaking Change, Needs Triage
Document "neg_root_mean_squared_error" in the "scoring" parameter

### Describe the workflow you want to enable

I would like users to be able to do:
```
cross_val_score(estimator, X, y, scroring="neg_root_mean_squared_error")
```
This is currently possible by specifying "neg_mean_squared_error" and taking the squared root (negating the sign). 

I would like to make this easier, because I think that the RMSE should be used more, as it gives a result in the same units as the units of y (for instance dollars if y is in dollars).

### Describe your proposed solution

Add a scorer that use mean_squared_error(..., squared=False) to the SCORERS dict in sklearn/metrics/_scorer.py, and update the docs (for instance in doc/modules/model_evaluation.rst, but I would inspect the different files where neg_mean_squared_error appears (for instance, found by "git grep neg_mean_squared_error") and consider on a case by case if the new function should be applied.

### Describe alternatives you've considered, if relevant

Specifying "neg_mean_squared_error" and taking the squared root (negating the sign)

### Additional context

_No response_

COMMENT:
Yes, it's a documentation problem actually. I had missed it.

Labels: New Feature, Documentation, Moderate, module:metrics, Breaking Change, Needs Triage
Document "neg_root_mean_squared_error" in the "scoring" parameter

### Describe the workflow you want to enable

I would like users to be able to do:
```
cross_val_score(estimator, X, y, scroring="neg_root_mean_squared_error")
```
This is currently possible by specifying "neg_mean_squared_error" and taking the squared root (negating the sign). 

I would like to make this easier, because I think that the RMSE should be used more, as it gives a result in the same units as the units of y (for instance dollars if y is in dollars).

### Describe your proposed solution

Add a scorer that use mean_squared_error(..., squared=False) to the SCORERS dict in sklearn/metrics/_scorer.py, and update the docs (for instance in doc/modules/model_evaluation.rst, but I would inspect the different files where neg_mean_squared_error appears (for instance, found by "git grep neg_mean_squared_error") and consider on a case by case if the new function should be applied.

### Describe alternatives you've considered, if relevant

Specifying "neg_mean_squared_error" and taking the squared root (negating the sign)

### Additional context

_No response_

COMMENT:
This is an error between the chair and the keyboard. Sorry, the documentation is correct.

Labels: New Feature, Documentation, Moderate, module:metrics, Breaking Change, Needs Triage
Should not use `collections.abc.Sequence` to ducktype `ndarray`

We have a bug in all estimators that are using `Sequence` to duck-type array-like. Such `collections.abc.Sequence` does not work for `ndarray`.

```python
In [17]: import numpy as np
    ...: from sklearn.covariance import GraphicalLassoCV
    ...: true_cov = np.array([[0.8, 0.0, 0.2, 0.0],
    ...:                      [0.0, 0.4, 0.0, 0.0],
    ...:                      [0.2, 0.0, 0.3, 0.1],
    ...:                      [0.0, 0.0, 0.1, 0.7]])
    ...: np.random.seed(0)
    ...: X = np.random.multivariate_normal(mean=[0, 0, 0, 0],
    ...:                                   cov=true_cov,
    ...:                                   size=200)
    ...: cov = GraphicalLassoCV(alphas=np.logspace(-2, 0, 5)).fit(X)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-17-d146d44e2bc4> in <module>
      9                                   cov=true_cov,
     10                                   size=200)
---> 11 cov = GraphicalLassoCV(alphas=np.logspace(-2, 0, 5)).fit(X)

~/Documents/packages/scikit-learn/sklearn/covariance/_graph_lasso.py in fit(self, X, y)
    865             alpha_1 = alpha_max(emp_cov)
    866             alpha_0 = 1e-2 * alpha_1
--> 867             alphas = np.logspace(np.log10(alpha_0), np.log10(alpha_1), n_alphas)[::-1]
    868 
    869         t0 = time.time()

<__array_function__ internals> in logspace(*args, **kwargs)

~/mambaforge/envs/dev/lib/python3.8/site-packages/numpy/core/function_base.py in logspace(start, stop, num, endpoint, base, dtype, axis)
    273 
    274     """
--> 275     y = linspace(start, stop, num=num, endpoint=endpoint, axis=axis)
    276     if dtype is None:
    277         return _nx.power(base, y)

<__array_function__ internals> in linspace(*args, **kwargs)

~/mambaforge/envs/dev/lib/python3.8/site-packages/numpy/core/function_base.py in linspace(start, stop, num, endpoint, retstep, dtype, axis)
    118 
    119     """
--> 120     num = operator.index(num)
    121     if num < 0:
    122         raise ValueError("Number of samples, %s, must be non-negative." % num)

TypeError: only integer scalar arrays can be converted to a scalar index
```

It boils down to:

```python
In [1]: import numpy as np

In [2]: from collections.abc import Sequence, Iterable

In [3]: isinstance(np.arange(3), Sequence)
Out[3]: False

In [4]: isinstance(np.arange(3), Iterable)
Out[4]: True
```

where we wrongly use `Sequence` on `ndarray`.

COMMENT:
I think the full solution is in https://github.com/scikit-learn/scikit-learn/pull/22154 

```python
def _is_arraylike_not_scalar(array):
    """Return True if array is array-like and not a scalar"""
    return _is_arraylike(array) and not np.isscalar(array)
```

Usually our "array-like" means "array-like" but not a numpy scalar or a string.

Labels: Bug