Talip7/scikit-learn-issues-multilabel huggingface dataset:
1 threads instead of multi-threading

### Describe the bug

Hello, I have a question regarding the following code: why is it running with only one thread instead of utilizing multiple threads? Thank you for your assistance.

X shape :(90, 16384) Y shape:  (90, 261880)
R=RidgeCV(alphas=[0.1, 1, 100], gcv_mode='svd').fit(X, Y)

the output of `pprint(threadpool_info())` is 

```python
[{'filepath': '/cvmfs/[../gentoo/2020/usr/lib64/gcc/x86_64-pc-linux-gnu/11.3.0/libgomp.so.1.0.0](http://../gentoo/2020/usr/lib64/gcc/x86_64-pc-linux-gnu/11.3.0/libgomp.so.1.0.0)',
  'internal_api': 'openmp',
  'num_threads': 1,
  'prefix': 'libgomp',
  'user_api': 'openmp',
  'version': None},
 {'architecture': 'zen2',
  'filepath': '/cvmfs/[../easybuild/software/2020/avx2/Core/bliscore/0.8.1/lib/libblis.so.3.0.1](http://../easybuild/software/2020/avx2/Core/bliscore/0.8.1/lib/libblis.so.3.0.1)',
  'internal_api': 'blis',
  'num_threads': 1,
  'prefix': 'libblis',
  'threading_layer': 'openmp',
  'user_api': 'blas',
  'version': '0.8.1'}]
```
### Steps/Code to Reproduce

X shape :(90, 16384) Y shape:  (90, 261880)
R=RidgeCV(alphas=[0.1, 1, 100], gcv_mode='svd').fit(X, Y)

then pprint(threadpool_info()) .


### Expected Results

execution through multi-threading

### Actual Results

utilizing only one thread

### Versions

```shell
sklearn version 1.3.0
python 3.10
```

COMMENT:
It's possible that the blis library you are using has been configured to only use one threads. The fact the your libgomp install is also configured to only use a single thread is peculiar though.

Feel free to try again by setting a conda environment and install all dependencies from conda-forge for instance.

```
conda create -n tmpenv -c conda-forge scikit-learn threadpoolctl
conda activate tmpenv
python -m threadpoolctl -i sklearn
```

(you can install conda from miniforge: https://github.com/conda-forge/miniforge).

then you can delete the env with:

```
conda deactive
conda env remove -n tmpenv
```

Please also check that you have access to more than 1 core on this machine, for instance by using `os.cpu_count()` or `joblib.cpu_count()` (the latter can accept `only_physical_cores=True` to ignore SMT logical cores).

Labels: Bug
1 threads instead of multi-threading

### Describe the bug

Hello, I have a question regarding the following code: why is it running with only one thread instead of utilizing multiple threads? Thank you for your assistance.

X shape :(90, 16384) Y shape:  (90, 261880)
R=RidgeCV(alphas=[0.1, 1, 100], gcv_mode='svd').fit(X, Y)

the output of `pprint(threadpool_info())` is 

```python
[{'filepath': '/cvmfs/[../gentoo/2020/usr/lib64/gcc/x86_64-pc-linux-gnu/11.3.0/libgomp.so.1.0.0](http://../gentoo/2020/usr/lib64/gcc/x86_64-pc-linux-gnu/11.3.0/libgomp.so.1.0.0)',
  'internal_api': 'openmp',
  'num_threads': 1,
  'prefix': 'libgomp',
  'user_api': 'openmp',
  'version': None},
 {'architecture': 'zen2',
  'filepath': '/cvmfs/[../easybuild/software/2020/avx2/Core/bliscore/0.8.1/lib/libblis.so.3.0.1](http://../easybuild/software/2020/avx2/Core/bliscore/0.8.1/lib/libblis.so.3.0.1)',
  'internal_api': 'blis',
  'num_threads': 1,
  'prefix': 'libblis',
  'threading_layer': 'openmp',
  'user_api': 'blas',
  'version': '0.8.1'}]
```
### Steps/Code to Reproduce

X shape :(90, 16384) Y shape:  (90, 261880)
R=RidgeCV(alphas=[0.1, 1, 100], gcv_mode='svd').fit(X, Y)

then pprint(threadpool_info()) .


### Expected Results

execution through multi-threading

### Actual Results

utilizing only one thread

### Versions

```shell
sklearn version 1.3.0
python 3.10
```

COMMENT:
Closing as it seems to be a user config issue.

Labels: Bug
⚠️ CI failed on Linux_nogil.pylatest_pip_nogil ⚠️

**CI failed on [Linux_nogil.pylatest_pip_nogil](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=58769&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5)** (Sep 08, 2023)
- test_pairwise_distances_argkmin[52-float32-parallel_on_X-braycurtis-1000000.0-500]
- test_pairwise_distances_argkmin[52-float32-parallel_on_Y-braycurtis-1000000.0-500]

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=59230&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5) on Sep 16, 2023

Labels: Needs Triage
Implementation of Order Recursive Matching Pursuit

### Describe the workflow you want to enable

The sparse linear regression problem is the NP-hard problem of performing ordinary L² linear regression with the catch that at most a fixed number of the resulting coefficients can be non-zero (or the variation in which one wants as few non-zero columns as possible while reaching a given score). Scikit-learn includes a greedy approximation algorithm for solving this problem in the form of [`sklearn.linear_model.OrthogonalMatchingPursuit`](https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.OrthogonalMatchingPursuit.html#sklearn.linear_model.OrthogonalMatchingPursuit) (OMP).

Many variations on this algorithm exist; one of them (which dates back [at least to the 70s](https://www.jstor.org/stable/1267353)) is "Order Recursive Matching Pursuit" (ORMP). Like OMP, ORMP is an iterative algorithm which picks one column from the input at a time, while maintaining the current residual. In OMP, one picks the column whose angle with the current residual is minimal, whereas in ORMP, one chooses the column resulting in the minimal residual. That is, while the approach is still greedy, it's somewhat more to the point, choosing the column leading to the minimal objective in each step. A priori, the cost of this approach is increased computational time, but with proper care, it is possible to make a [simple implementation](https://github.com/Kvantify/ormp/blob/master/src/ormp/impl_np.py) that rivals the runtime performance of the existing OMP implementation, and is faster on the instances that motivated the work.

### Describe your proposed solution

In our company, we needed fit accuracy greater than what could be achieved with OMP and thus implemented ORMP in a handful of different ways. The implementations are available on https://github.com/Kvantify/ormp. As I believe it fits the inclusion criteria, these implementations could be lifted into scikit-learn more or less directly, some parts of it more relevant than others: I imagine we don't want a JAX dependency in scikit-learn, for example, but note that even the pure NumPy implementation appears to be generally faster than scikit-learn's existing OMP, while delivering the promised score improvements on typical (but far from all) problem instances. See the README in that repository for [a few crude performance benchmarks](https://github.com/Kvantify/ormp#choosing-an-implementation) and [notes on a result quality comparison with OMP](https://github.com/Kvantify/ormp#comparison-with-orthogonal-matching-pursuit).

We can submit a pull request if you are interested.

COMMENT:
Maybe @agramfort have some knowledge about it. I assume that we would not be against the inclusion of a pure NumPy implementation. We would only need to have a proper benchmark against the current OMP solver.

I would probably use a `solver` parameter in the current `OrthogonalMatchingPursuit` instead of creating a new class. We would also need a set of tests.

Depending on the benchmark we could eventually use it as a default solver.

Labels: Enhancement
Implementation of Order Recursive Matching Pursuit

### Describe the workflow you want to enable

The sparse linear regression problem is the NP-hard problem of performing ordinary L² linear regression with the catch that at most a fixed number of the resulting coefficients can be non-zero (or the variation in which one wants as few non-zero columns as possible while reaching a given score). Scikit-learn includes a greedy approximation algorithm for solving this problem in the form of [`sklearn.linear_model.OrthogonalMatchingPursuit`](https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.OrthogonalMatchingPursuit.html#sklearn.linear_model.OrthogonalMatchingPursuit) (OMP).

Many variations on this algorithm exist; one of them (which dates back [at least to the 70s](https://www.jstor.org/stable/1267353)) is "Order Recursive Matching Pursuit" (ORMP). Like OMP, ORMP is an iterative algorithm which picks one column from the input at a time, while maintaining the current residual. In OMP, one picks the column whose angle with the current residual is minimal, whereas in ORMP, one chooses the column resulting in the minimal residual. That is, while the approach is still greedy, it's somewhat more to the point, choosing the column leading to the minimal objective in each step. A priori, the cost of this approach is increased computational time, but with proper care, it is possible to make a [simple implementation](https://github.com/Kvantify/ormp/blob/master/src/ormp/impl_np.py) that rivals the runtime performance of the existing OMP implementation, and is faster on the instances that motivated the work.

### Describe your proposed solution

In our company, we needed fit accuracy greater than what could be achieved with OMP and thus implemented ORMP in a handful of different ways. The implementations are available on https://github.com/Kvantify/ormp. As I believe it fits the inclusion criteria, these implementations could be lifted into scikit-learn more or less directly, some parts of it more relevant than others: I imagine we don't want a JAX dependency in scikit-learn, for example, but note that even the pure NumPy implementation appears to be generally faster than scikit-learn's existing OMP, while delivering the promised score improvements on typical (but far from all) problem instances. See the README in that repository for [a few crude performance benchmarks](https://github.com/Kvantify/ormp#choosing-an-implementation) and [notes on a result quality comparison with OMP](https://github.com/Kvantify/ormp#comparison-with-orthogonal-matching-pursuit).

We can submit a pull request if you are interested.

COMMENT:
We could also probably use array namespace here to enable using JAX? But I agree adding it as a different `solver` is probably an easier path forward.

Labels: Enhancement
Implementation of Order Recursive Matching Pursuit

### Describe the workflow you want to enable

The sparse linear regression problem is the NP-hard problem of performing ordinary L² linear regression with the catch that at most a fixed number of the resulting coefficients can be non-zero (or the variation in which one wants as few non-zero columns as possible while reaching a given score). Scikit-learn includes a greedy approximation algorithm for solving this problem in the form of [`sklearn.linear_model.OrthogonalMatchingPursuit`](https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.OrthogonalMatchingPursuit.html#sklearn.linear_model.OrthogonalMatchingPursuit) (OMP).

Many variations on this algorithm exist; one of them (which dates back [at least to the 70s](https://www.jstor.org/stable/1267353)) is "Order Recursive Matching Pursuit" (ORMP). Like OMP, ORMP is an iterative algorithm which picks one column from the input at a time, while maintaining the current residual. In OMP, one picks the column whose angle with the current residual is minimal, whereas in ORMP, one chooses the column resulting in the minimal residual. That is, while the approach is still greedy, it's somewhat more to the point, choosing the column leading to the minimal objective in each step. A priori, the cost of this approach is increased computational time, but with proper care, it is possible to make a [simple implementation](https://github.com/Kvantify/ormp/blob/master/src/ormp/impl_np.py) that rivals the runtime performance of the existing OMP implementation, and is faster on the instances that motivated the work.

### Describe your proposed solution

In our company, we needed fit accuracy greater than what could be achieved with OMP and thus implemented ORMP in a handful of different ways. The implementations are available on https://github.com/Kvantify/ormp. As I believe it fits the inclusion criteria, these implementations could be lifted into scikit-learn more or less directly, some parts of it more relevant than others: I imagine we don't want a JAX dependency in scikit-learn, for example, but note that even the pure NumPy implementation appears to be generally faster than scikit-learn's existing OMP, while delivering the promised score improvements on typical (but far from all) problem instances. See the README in that repository for [a few crude performance benchmarks](https://github.com/Kvantify/ormp#choosing-an-implementation) and [notes on a result quality comparison with OMP](https://github.com/Kvantify/ormp#comparison-with-orthogonal-matching-pursuit).

We can submit a pull request if you are interested.

COMMENT:
I find the numbers in
https://github.com/Kvantify/ormp#comparison-with-orthogonal-matching-pursuit
pretty compelling.
I would not have expected such a big difference due to greedy
selection criteria.

Labels: Enhancement
Implementation of Order Recursive Matching Pursuit

### Describe the workflow you want to enable

The sparse linear regression problem is the NP-hard problem of performing ordinary L² linear regression with the catch that at most a fixed number of the resulting coefficients can be non-zero (or the variation in which one wants as few non-zero columns as possible while reaching a given score). Scikit-learn includes a greedy approximation algorithm for solving this problem in the form of [`sklearn.linear_model.OrthogonalMatchingPursuit`](https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.OrthogonalMatchingPursuit.html#sklearn.linear_model.OrthogonalMatchingPursuit) (OMP).

Many variations on this algorithm exist; one of them (which dates back [at least to the 70s](https://www.jstor.org/stable/1267353)) is "Order Recursive Matching Pursuit" (ORMP). Like OMP, ORMP is an iterative algorithm which picks one column from the input at a time, while maintaining the current residual. In OMP, one picks the column whose angle with the current residual is minimal, whereas in ORMP, one chooses the column resulting in the minimal residual. That is, while the approach is still greedy, it's somewhat more to the point, choosing the column leading to the minimal objective in each step. A priori, the cost of this approach is increased computational time, but with proper care, it is possible to make a [simple implementation](https://github.com/Kvantify/ormp/blob/master/src/ormp/impl_np.py) that rivals the runtime performance of the existing OMP implementation, and is faster on the instances that motivated the work.

### Describe your proposed solution

In our company, we needed fit accuracy greater than what could be achieved with OMP and thus implemented ORMP in a handful of different ways. The implementations are available on https://github.com/Kvantify/ormp. As I believe it fits the inclusion criteria, these implementations could be lifted into scikit-learn more or less directly, some parts of it more relevant than others: I imagine we don't want a JAX dependency in scikit-learn, for example, but note that even the pure NumPy implementation appears to be generally faster than scikit-learn's existing OMP, while delivering the promised score improvements on typical (but far from all) problem instances. See the README in that repository for [a few crude performance benchmarks](https://github.com/Kvantify/ormp#choosing-an-implementation) and [notes on a result quality comparison with OMP](https://github.com/Kvantify/ormp#comparison-with-orthogonal-matching-pursuit).

We can submit a pull request if you are interested.

COMMENT:
Hi! I'd like to work on this issue. If it's still available, I'd be happy to take it. I can implement the NumPy version and set up proper benchmarking as discussed above. Thank you!

Labels: Enhancement
Implementation of Order Recursive Matching Pursuit

### Describe the workflow you want to enable

The sparse linear regression problem is the NP-hard problem of performing ordinary L² linear regression with the catch that at most a fixed number of the resulting coefficients can be non-zero (or the variation in which one wants as few non-zero columns as possible while reaching a given score). Scikit-learn includes a greedy approximation algorithm for solving this problem in the form of [`sklearn.linear_model.OrthogonalMatchingPursuit`](https://scikit-learn.org/stable/modules/generated/sklearn.linear_model.OrthogonalMatchingPursuit.html#sklearn.linear_model.OrthogonalMatchingPursuit) (OMP).

Many variations on this algorithm exist; one of them (which dates back [at least to the 70s](https://www.jstor.org/stable/1267353)) is "Order Recursive Matching Pursuit" (ORMP). Like OMP, ORMP is an iterative algorithm which picks one column from the input at a time, while maintaining the current residual. In OMP, one picks the column whose angle with the current residual is minimal, whereas in ORMP, one chooses the column resulting in the minimal residual. That is, while the approach is still greedy, it's somewhat more to the point, choosing the column leading to the minimal objective in each step. A priori, the cost of this approach is increased computational time, but with proper care, it is possible to make a [simple implementation](https://github.com/Kvantify/ormp/blob/master/src/ormp/impl_np.py) that rivals the runtime performance of the existing OMP implementation, and is faster on the instances that motivated the work.

### Describe your proposed solution

In our company, we needed fit accuracy greater than what could be achieved with OMP and thus implemented ORMP in a handful of different ways. The implementations are available on https://github.com/Kvantify/ormp. As I believe it fits the inclusion criteria, these implementations could be lifted into scikit-learn more or less directly, some parts of it more relevant than others: I imagine we don't want a JAX dependency in scikit-learn, for example, but note that even the pure NumPy implementation appears to be generally faster than scikit-learn's existing OMP, while delivering the promised score improvements on typical (but far from all) problem instances. See the README in that repository for [a few crude performance benchmarks](https://github.com/Kvantify/ormp#choosing-an-implementation) and [notes on a result quality comparison with OMP](https://github.com/Kvantify/ormp#comparison-with-orthogonal-matching-pursuit).

We can submit a pull request if you are interested.

COMMENT:
@casey2346 this is not an easy issue, but if you think you're up for it, sure, give it a shot.

Labels: Enhancement
I can not achieve inplace scaling by using sklearn.preprocessing.minmax_scale

### Describe the bug

## By setting the copy=False, ndarray data has not changed unexpectedly
![image](https://github.com/scikit-learn/scikit-learn/assets/68744203/78b636a1-1556-4f79-a5be-7f683ba45094)

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import sklearn.preprocessing as pre

np.random.seed(10)
data = np.random.randint(1, 10, size=(5, 3))
print(data)
pre.minmax_scale(data, feature_range=(0, 1), axis=0, copy=False)
print(data)
```

### Expected Results

## A reasonable explanation about the copy parameter of minmax_scala funciton

### Actual Results

# There are no warings and errors, just the result is not wrong!
![image](https://github.com/scikit-learn/scikit-learn/assets/68744203/1fdcc7df-f763-41bc-8e58-bd4f0e856b91)


### Versions

```shell
Python dependencies:
      sklearn: 1.3.0
          pip: 23.2.1
   setuptools: 65.5.0
        numpy: 1.25.2
        scipy: 1.11.2
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.2
threadpoolctl: 3.2.0
```

COMMENT:
`copy=False` only works if the input array dtype is a float dtype, i.e. `float64`, `float32` or `float16` right now. I guess maybe the documentation could be improved to mention this?

In your case the input array dtype is an int dtype.

Labels: Documentation
I can not achieve inplace scaling by using sklearn.preprocessing.minmax_scale

### Describe the bug

## By setting the copy=False, ndarray data has not changed unexpectedly
![image](https://github.com/scikit-learn/scikit-learn/assets/68744203/78b636a1-1556-4f79-a5be-7f683ba45094)

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import sklearn.preprocessing as pre

np.random.seed(10)
data = np.random.randint(1, 10, size=(5, 3))
print(data)
pre.minmax_scale(data, feature_range=(0, 1), axis=0, copy=False)
print(data)
```

### Expected Results

## A reasonable explanation about the copy parameter of minmax_scala funciton

### Actual Results

# There are no warings and errors, just the result is not wrong!
![image](https://github.com/scikit-learn/scikit-learn/assets/68744203/1fdcc7df-f763-41bc-8e58-bd4f0e856b91)


### Versions

```shell
Python dependencies:
      sklearn: 1.3.0
          pip: 23.2.1
   setuptools: 65.5.0
        numpy: 1.25.2
        scipy: 1.11.2
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.2
threadpoolctl: 3.2.0
```

COMMENT:
After [this line](https://github.com/scikit-learn/scikit-learn/blob/a31e1085e13af88a22d6c983192d54a58eaa845b/sklearn/preprocessing/_data.py#L649)
There is a new instance of X and the data type of new one is float.
So maybe you should modify your code to below.
`data=pre.minmax_scale(data, feature_range=(0, 1), axis=0, copy=False)`

Labels: Documentation
I can not achieve inplace scaling by using sklearn.preprocessing.minmax_scale

### Describe the bug

## By setting the copy=False, ndarray data has not changed unexpectedly
![image](https://github.com/scikit-learn/scikit-learn/assets/68744203/78b636a1-1556-4f79-a5be-7f683ba45094)

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import sklearn.preprocessing as pre

np.random.seed(10)
data = np.random.randint(1, 10, size=(5, 3))
print(data)
pre.minmax_scale(data, feature_range=(0, 1), axis=0, copy=False)
print(data)
```

### Expected Results

## A reasonable explanation about the copy parameter of minmax_scala funciton

### Actual Results

# There are no warings and errors, just the result is not wrong!
![image](https://github.com/scikit-learn/scikit-learn/assets/68744203/1fdcc7df-f763-41bc-8e58-bd4f0e856b91)


### Versions

```shell
Python dependencies:
      sklearn: 1.3.0
          pip: 23.2.1
   setuptools: 65.5.0
        numpy: 1.25.2
        scipy: 1.11.2
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.2
threadpoolctl: 3.2.0
```

COMMENT:
> `copy=False` only works if the input array dtype is a float dtype, i.e. `float64`, `float32` or `float16` right now. I guess maybe the documentation could be improved to mention this?
> 
> In your case the input array dtype is an int dtype.

Yes, thanks for you answer! The official doc really needs an improvement.

Labels: Documentation