Talip7/scikit-learn-issues-multilabel huggingface dataset:
Weights are being normalized using number of samples as opposed to sum in GaussianMixture

### Describe the bug

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Steps/Code to Reproduce

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Expected Results

Correct weights.

### Actual Results

Incorrect weights.

### Versions

```shell
System:
    python: 3.9.13 (main, May 24 2022, 21:28:31)  [Clang 13.1.6 (clang-1316.0.21.2)]
executable: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/bin/python
   machine: macOS-12.4-x86_64-i386-64bit

Python dependencies:
      sklearn: 1.1.1
          pip: 22.2.1
   setuptools: 62.3.2
        numpy: 1.23.1
        scipy: 1.8.1
       Cython: 0.29.30
       pandas: 1.4.3
   matplotlib: 3.5.2
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: False

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/scipy/.dylibs/libopenblas.0.dylib
        version: 0.3.17
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8
```

COMMENT:
I can work on this if still available.

Labels: Bug, Moderate, module:mixture
Weights are being normalized using number of samples as opposed to sum in GaussianMixture

### Describe the bug

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Steps/Code to Reproduce

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Expected Results

Correct weights.

### Actual Results

Incorrect weights.

### Versions

```shell
System:
    python: 3.9.13 (main, May 24 2022, 21:28:31)  [Clang 13.1.6 (clang-1316.0.21.2)]
executable: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/bin/python
   machine: macOS-12.4-x86_64-i386-64bit

Python dependencies:
      sklearn: 1.1.1
          pip: 22.2.1
   setuptools: 62.3.2
        numpy: 1.23.1
        scipy: 1.8.1
       Cython: 0.29.30
       pandas: 1.4.3
   matplotlib: 3.5.2
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: False

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/scipy/.dylibs/libopenblas.0.dylib
        version: 0.3.17
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8
```

COMMENT:
Seems like a simple fix. Note that a similar change was made in PR #23034, addressing an error reported in #23032.

Labels: Bug, Moderate, module:mixture
Weights are being normalized using number of samples as opposed to sum in GaussianMixture

### Describe the bug

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Steps/Code to Reproduce

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Expected Results

Correct weights.

### Actual Results

Incorrect weights.

### Versions

```shell
System:
    python: 3.9.13 (main, May 24 2022, 21:28:31)  [Clang 13.1.6 (clang-1316.0.21.2)]
executable: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/bin/python
   machine: macOS-12.4-x86_64-i386-64bit

Python dependencies:
      sklearn: 1.1.1
          pip: 22.2.1
   setuptools: 62.3.2
        numpy: 1.23.1
        scipy: 1.8.1
       Cython: 0.29.30
       pandas: 1.4.3
   matplotlib: 3.5.2
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: False

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/scipy/.dylibs/libopenblas.0.dylib
        version: 0.3.17
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8
```

COMMENT:
Hi @kshitijgoel007, thank you for reporting this.

Do you by change have a minimal reproducible example where this incorrect weighting cause problem?

Labels: Bug, Moderate, module:mixture
Weights are being normalized using number of samples as opposed to sum in GaussianMixture

### Describe the bug

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Steps/Code to Reproduce

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Expected Results

Correct weights.

### Actual Results

Incorrect weights.

### Versions

```shell
System:
    python: 3.9.13 (main, May 24 2022, 21:28:31)  [Clang 13.1.6 (clang-1316.0.21.2)]
executable: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/bin/python
   machine: macOS-12.4-x86_64-i386-64bit

Python dependencies:
      sklearn: 1.1.1
          pip: 22.2.1
   setuptools: 62.3.2
        numpy: 1.23.1
        scipy: 1.8.1
       Cython: 0.29.30
       pandas: 1.4.3
   matplotlib: 3.5.2
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: False

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/scipy/.dylibs/libopenblas.0.dylib
        version: 0.3.17
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8
```

COMMENT:
I can work on this, if he has not yet been finished.

Labels: Bug, Moderate, module:mixture
Weights are being normalized using number of samples as opposed to sum in GaussianMixture

### Describe the bug

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Steps/Code to Reproduce

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Expected Results

Correct weights.

### Actual Results

Incorrect weights.

### Versions

```shell
System:
    python: 3.9.13 (main, May 24 2022, 21:28:31)  [Clang 13.1.6 (clang-1316.0.21.2)]
executable: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/bin/python
   machine: macOS-12.4-x86_64-i386-64bit

Python dependencies:
      sklearn: 1.1.1
          pip: 22.2.1
   setuptools: 62.3.2
        numpy: 1.23.1
        scipy: 1.8.1
       Cython: 0.29.30
       pandas: 1.4.3
   matplotlib: 3.5.2
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: False

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/scipy/.dylibs/libopenblas.0.dylib
        version: 0.3.17
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8
```

COMMENT:
@emirkmo I kind of agree with the principle of not renormalizing user-defined weights.

What I am wondering however is that it makes little sense to have unnormalized weight at the init that will get normalized in the next M-steps. Intuitively, I would expect the same normalization (or non-normalization) for the full iterative algorithm.

Labels: Bug, Moderate, module:mixture
Weights are being normalized using number of samples as opposed to sum in GaussianMixture

### Describe the bug

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Steps/Code to Reproduce

Weights are being normalized at Line https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L718 using `n_samples`. It should be done using `weights.sum()` as
done in `_m_step()` here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/mixture/_gaussian_mixture.py#L756.

### Expected Results

Correct weights.

### Actual Results

Incorrect weights.

### Versions

```shell
System:
    python: 3.9.13 (main, May 24 2022, 21:28:31)  [Clang 13.1.6 (clang-1316.0.21.2)]
executable: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/bin/python
   machine: macOS-12.4-x86_64-i386-64bit

Python dependencies:
      sklearn: 1.1.1
          pip: 22.2.1
   setuptools: 62.3.2
        numpy: 1.23.1
        scipy: 1.8.1
       Cython: 0.29.30
       pandas: 1.4.3
   matplotlib: 3.5.2
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: False

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/numpy/.dylibs/libopenblas64_.0.dylib
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/kshitijgoel/Documents/main/code.nosync/self_organizing_gmm/.venv/lib/python3.9/site-packages/scipy/.dylibs/libopenblas.0.dylib
        version: 0.3.17
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8
```

COMMENT:
@glemaitre The init step really is a way to fine tune the path the algorithm will take. For some use cases it actually barely matters at all. But for many others, it can be really important as the EM algorithm is highly sensitive to initial state. (This can be especially important for sparse multi-D data.)

 So ultimately I don't think the rest of the algorithm has much to do with the init state. In fact, the initial state does not even have to be super well defined, as the M-steps seem capable of handling that in my testing.

What is most important is, (without creating bugs like overflow that can lead to negative normalization in the M-steps), allowing precisely specifying the init state, and providing tools for users to do this easily/intelligently as well. (I'll shamelessly link to #24812). 

Otherwise, it is like trying to stack magnetic blocks. As you go to place it just so, the system shifts by itself and the end result isn't what you want. Very frustrating.

Labels: Bug, Moderate, module:mixture
OrdinalEncoder fails inverse_transform with np.nan as

# Describe the bug

I want to use inverse_transform on the OrdinalEncoder from and to np.nan. 

Steps/Code to Reproduce
```python
from sklearn.preprocessing import OrdinalEncoder
import numpy as np

enc = OrdinalEncoder(handle_unknown="use_encoded_value", unknown_value=np.nan, encoded_missing_value=np.nan)

X_train = [["a", "1"]]
enc.fit(X_train)

X_test = [["c", "1"]]
X_test_encoded= enc.transform(X_test)
X_test_decoded = enc.inverse_transform(X_test_encoded)
```

# Actual result
```
Traceback (most recent call last):
  File "/home/ME/.pyenv/versions/3.10.4/lib/python3.10/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<input>", line 1, in <module>
  File "/home/ME/.local/share/virtualenvs/python-XEcZKjNR/lib/python3.10/site-packages/sklearn/preprocessing/_encoders.py", line 1420, in inverse_transform
    X_tr[:, i] = self.categories_[i][np.where(unknown_labels, 0, labels)]
IndexError: index -9223372036854775808 is out of bounds for axis 0 with size 1
```

# Expected result

I expected that np.nan inverse transform is the same as `unknown_value`, so also np.nan in this case. The expected array would be `[np.nan, 0]`. As this might be a dtype problem (nan as float, rest of array might be string), None would also be an option

Versions

```
python==3.10.4
scikit-learn==1.1.1
numpy==1.22.4
```

COMMENT:
I am not able to reproduce this issue locally with the versions you provided. Can you provide the OS you are running?

As for the expected value: `unknown_value` should really be `encoded_unknown_value`, it is what categories are encoded into if they are unknown. The dataset has shape `(1, 2)`, `OrdinalEncoder` treats this as 1 sample with 2 features. You may have meant for this to be 1 feature, but I'll do the analysis on it being 1 sample with 2 features:

The values I get for `X_test_encoded` is `[[nan,  0.]]` and `X_test_decoded` is `[['a', '1']]`:

- Feature index 0: `'c'` is unknown so it is transformed to `nan`. When inverse transforming, I think `nan` should be considered unknown because there is no missing value in the feature 0, which means it should return `None`. Returning `'a'` feels like a bug. If there was a missing value in the training set for feature 0, then there is no way to know if an encoded `nan` means unknown or missing. In that case, I'll side with it being missing, which is an opinionated choice.
- Feature index 1: `'1'` is transformmed to 0 and inverse transform is back to `'1'`. This is straight forward since the categories are known and not missing.

Labels: Bug, module:preprocessing
OrdinalEncoder fails inverse_transform with np.nan as

# Describe the bug

I want to use inverse_transform on the OrdinalEncoder from and to np.nan. 

Steps/Code to Reproduce
```python
from sklearn.preprocessing import OrdinalEncoder
import numpy as np

enc = OrdinalEncoder(handle_unknown="use_encoded_value", unknown_value=np.nan, encoded_missing_value=np.nan)

X_train = [["a", "1"]]
enc.fit(X_train)

X_test = [["c", "1"]]
X_test_encoded= enc.transform(X_test)
X_test_decoded = enc.inverse_transform(X_test_encoded)
```

# Actual result
```
Traceback (most recent call last):
  File "/home/ME/.pyenv/versions/3.10.4/lib/python3.10/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<input>", line 1, in <module>
  File "/home/ME/.local/share/virtualenvs/python-XEcZKjNR/lib/python3.10/site-packages/sklearn/preprocessing/_encoders.py", line 1420, in inverse_transform
    X_tr[:, i] = self.categories_[i][np.where(unknown_labels, 0, labels)]
IndexError: index -9223372036854775808 is out of bounds for axis 0 with size 1
```

# Expected result

I expected that np.nan inverse transform is the same as `unknown_value`, so also np.nan in this case. The expected array would be `[np.nan, 0]`. As this might be a dtype problem (nan as float, rest of array might be string), None would also be an option

Versions

```
python==3.10.4
scikit-learn==1.1.1
numpy==1.22.4
```

COMMENT:
Thanks @Micky774. I can reproduce on Linux. `np.asarray([np.nan]).astype(np.int64)` is undefined behavior and returns different results depending on the platform.

Labels: Bug, module:preprocessing
Deprecation warning with scipy=1.9.0

### Describe the bug

When running a fit with a Ride regression model we get:

> DeprecationWarning: The 'sym_pos' keyword is deprecated and should be replaced by using 'assume_a = "pos"'. 'sym_pos' will be removed in SciPy 1.11.0.

Looking through the SciPy release notes, sym_pos was actually deprecated about 5 years ago, they just forgot to add the deprecation warning. Now that they have, it is probably best to make this change now before the sym_pos keyword is actually removed.

The argument is used 4 times within sklearn/linear_model/_ridge.py.



### Steps/Code to Reproduce

```
import warnings

from sklearn import linear_model

warnings.simplefilter('always', DeprecationWarning)

reg = linear_model.Ridge(alpha=0.5, solver='cholesky')
reg.fit([[0, 0], [0, 0], [1, 1]], [0, 0.1, 1])
```

### Expected Results

No warnings generated

### Actual Results

/usr/local/lib/python3.10/site-packages/sklearn/linear_model/_ridge.py:212: DeprecationWarning: The 'sym_pos' keyword is deprecated and should be replaced by using 'assume_a = "pos"'. 'sym_pos' will be removed in SciPy 1.11.0.
  return linalg.solve(A, Xy, sym_pos=True, overwrite_a=True).T

### Versions

```shell
System:
    python: 3.10.5 (main, Jul 13 2022, 05:45:22) [GCC 10.2.1 20210110]
executable: /usr/local/bin/python
   machine: Linux-5.15.0-43-generic-x86_64-with-glibc2.31

Python dependencies:
      sklearn: 1.1.1
          pip: 22.1.2
   setuptools: 58.1.0
        numpy: 1.23.1
        scipy: 1.9.0
       Cython: None
       pandas: 1.4.3
   matplotlib: 3.5.2
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /usr/local/lib/python3.10/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
    num_threads: 32

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /usr/local/lib/python3.10/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: Zen
    num_threads: 32

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /usr/local/lib/python3.10/site-packages/scipy.libs/libopenblasp-r0-9f9f5dbc.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Zen
    num_threads: 32
```

COMMENT:
Thank you for opening this issue! This was fixed in https://github.com/scikit-learn/scikit-learn/commit/4b9d5904752b4781e92988c4fdb09cb87b7a0e36.

I think it makes sense to include this change in `1.1.2` as a bug fix.

Labels: Bug
Deprecation warning with scipy=1.9.0

### Describe the bug

When running a fit with a Ride regression model we get:

> DeprecationWarning: The 'sym_pos' keyword is deprecated and should be replaced by using 'assume_a = "pos"'. 'sym_pos' will be removed in SciPy 1.11.0.

Looking through the SciPy release notes, sym_pos was actually deprecated about 5 years ago, they just forgot to add the deprecation warning. Now that they have, it is probably best to make this change now before the sym_pos keyword is actually removed.

The argument is used 4 times within sklearn/linear_model/_ridge.py.



### Steps/Code to Reproduce

```
import warnings

from sklearn import linear_model

warnings.simplefilter('always', DeprecationWarning)

reg = linear_model.Ridge(alpha=0.5, solver='cholesky')
reg.fit([[0, 0], [0, 0], [1, 1]], [0, 0.1, 1])
```

### Expected Results

No warnings generated

### Actual Results

/usr/local/lib/python3.10/site-packages/sklearn/linear_model/_ridge.py:212: DeprecationWarning: The 'sym_pos' keyword is deprecated and should be replaced by using 'assume_a = "pos"'. 'sym_pos' will be removed in SciPy 1.11.0.
  return linalg.solve(A, Xy, sym_pos=True, overwrite_a=True).T

### Versions

```shell
System:
    python: 3.10.5 (main, Jul 13 2022, 05:45:22) [GCC 10.2.1 20210110]
executable: /usr/local/bin/python
   machine: Linux-5.15.0-43-generic-x86_64-with-glibc2.31

Python dependencies:
      sklearn: 1.1.1
          pip: 22.1.2
   setuptools: 58.1.0
        numpy: 1.23.1
        scipy: 1.9.0
       Cython: None
       pandas: 1.4.3
   matplotlib: 3.5.2
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /usr/local/lib/python3.10/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
    num_threads: 32

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /usr/local/lib/python3.10/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: Zen
    num_threads: 32

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /usr/local/lib/python3.10/site-packages/scipy.libs/libopenblasp-r0-9f9f5dbc.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Zen
    num_threads: 32
```

COMMENT:
Should we add https://github.com/scikit-learn/scikit-learn/pull/23617 in the changelog for `1.1.2` or just close this issue as completed?

Labels: Bug