Talip7/scikit-learn-issues-multilabel huggingface dataset:
TypeError: cpu_count() got an unexpected keyword argument 'only_physical_cores'

### Describe the bug

I am running the KNeighbordsClassifier inside a framework of pytorch_lightning. I am fitting the model correctly, but when I try to predict new results I have an error.

### Steps/Code to Reproduce

```python
estimators = dict(svm=SVC(kernel='rbf', C=1e5, gamma=1.),
                  knn=KNeighborsClassifier(n_neighbors=3))

for key, estimator in estimators.items():
    estimator.fit(x_train, c_train)
    c_hat_test = np.concatenate([estimator.predict(x_te) for x_te in x_test_split], axis=0)
```

### Expected Results

No error is thrown

### Actual Results

```python
File "sklearn/metrics/_pairwise_distances_reduction/_argkmin.pyx", line 556, in sklearn.metrics._pairwise_distances_reduction._argkmin.ArgKmin32.compute
  File "sklearn/metrics/_pairwise_distances_reduction/_argkmin.pyx", line 820, in sklearn.metrics._pairwise_distances_reduction._argkmin.EuclideanArgKmin32.__init__
  File "sklearn/metrics/_pairwise_distances_reduction/_argkmin.pyx", line 590, in sklearn.metrics._pairwise_distances_reduction._argkmin.ArgKmin32.__init__
  File "sklearn/metrics/_pairwise_distances_reduction/_base.pyx", line 547, in sklearn.metrics._pairwise_distances_reduction._base.BaseDistancesReduction32.__init__
  File "sklearn/utils/_openmp_helpers.pyx", line 21, in sklearn.utils._openmp_helpers._openmp_effective_n_threads
  File "sklearn/utils/_openmp_helpers.pyx", line 68, in sklearn.utils._openmp_helpers._openmp_effective_n_threads
TypeError: cpu_count() got an unexpected keyword argument 'only_physical_cores'
```

### Versions

```shell
System:
    python: 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0]
executable: /home/myuser/anaconda3/envs/pt12/bin/python
   machine: Linux-6.5.0-21-generic-x86_64-with-glibc2.35
Python dependencies:
      sklearn: 1.4.1.post1
          pip: 23.3.1
   setuptools: 68.2.2
        numpy: 1.26.4
        scipy: 1.12.0
       Cython: 3.0.8
       pandas: 2.2.1
   matplotlib: 3.8.3
       joblib: 1.3.2
threadpoolctl: 3.3.0
Built with OpenMP: True
threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 12
         prefix: libgomp
       filepath: /home/myuser/anaconda3/envs/pt12/lib/python3.10/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: /home/myuser/anaconda3/envs/pt12/lib/python3.10/site-packages/numpy.libs/libopenblas64_p-r0-0cf96a72.3.23.dev.so
        version: 0.3.23.dev
threading_layer: pthreads
   architecture: Zen
       user_api: blas
   internal_api: openblas
    num_threads: 12
         prefix: libopenblas
       filepath: /home/myuser/anaconda3/envs/pt12/lib/python3.10/site-packages/scipy.libs/libopenblasp-r0-23e5df77.3.21.dev.so
        version: 0.3.21.dev
threading_layer: pthreads
   architecture: Zen
```

COMMENT:
I could resolve it by changing the precision of the dataset to float64 for input data and unit8 for labels in the classification task.

Labels: Bug
Missing _ZdlPv symbol in _argkmin_classmode for manylinux wheels produced by meson

The current work-around is to use `-fno-sized-deallocation` see https://github.com/scikit-learn/scikit-learn/pull/28506#discussion_r1512897297 for more details.

This can be reproduced locally with cibuildwheel.
```
python -m cibuildwheel --only cp312-manylinux_x86_64
```
will produced a manylinux wheel is in the wheelhouse folder which you can install through something like this:
```
pip install wheelhouse/scikit_learn-1.5.dev0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
```

Traceback from build log:
```
❯ python -c 'import sklearn.metrics'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/__init__.py", line 7, in <module>
    from . import cluster
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/cluster/__init__.py", line 25, in <module>
    from ._unsupervised import (
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/cluster/_unsupervised.py", line 23, in <module>
    from ..pairwise import _VALID_METRICS, pairwise_distances, pairwise_distances_chunked
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/pairwise.py", line 43, in <module>
    from ._pairwise_distances_reduction import ArgKmin
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/__init__.py", line 94, in <module>
    from ._dispatcher import (
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/_dispatcher.py", line 17, in <module>
    from ._argkmin_classmode import (
ImportError: /home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/_argkmin_classmode.cpython-312-x86_64-linux-gnu.so: undefined symbol: _ZdlPv
```

COMMENT:
Not urgent at all, but I assigned @jjerphan since he mentioned he may try at one point to look at it :pray: in https://github.com/scikit-learn/scikit-learn/pull/28506#discussion_r1515002112

Labels: Bug, Build / CI
Missing _ZdlPv symbol in _argkmin_classmode for manylinux wheels produced by meson

The current work-around is to use `-fno-sized-deallocation` see https://github.com/scikit-learn/scikit-learn/pull/28506#discussion_r1512897297 for more details.

This can be reproduced locally with cibuildwheel.
```
python -m cibuildwheel --only cp312-manylinux_x86_64
```
will produced a manylinux wheel is in the wheelhouse folder which you can install through something like this:
```
pip install wheelhouse/scikit_learn-1.5.dev0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
```

Traceback from build log:
```
❯ python -c 'import sklearn.metrics'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/__init__.py", line 7, in <module>
    from . import cluster
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/cluster/__init__.py", line 25, in <module>
    from ._unsupervised import (
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/cluster/_unsupervised.py", line 23, in <module>
    from ..pairwise import _VALID_METRICS, pairwise_distances, pairwise_distances_chunked
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/pairwise.py", line 43, in <module>
    from ._pairwise_distances_reduction import ArgKmin
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/__init__.py", line 94, in <module>
    from ._dispatcher import (
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/_dispatcher.py", line 17, in <module>
    from ._argkmin_classmode import (
ImportError: /home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/_argkmin_classmode.cpython-312-x86_64-linux-gnu.so: undefined symbol: _ZdlPv
```

COMMENT:
Definitely, I should look into that when I get some free time.

Labels: Bug, Build / CI
Missing _ZdlPv symbol in _argkmin_classmode for manylinux wheels produced by meson

The current work-around is to use `-fno-sized-deallocation` see https://github.com/scikit-learn/scikit-learn/pull/28506#discussion_r1512897297 for more details.

This can be reproduced locally with cibuildwheel.
```
python -m cibuildwheel --only cp312-manylinux_x86_64
```
will produced a manylinux wheel is in the wheelhouse folder which you can install through something like this:
```
pip install wheelhouse/scikit_learn-1.5.dev0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
```

Traceback from build log:
```
❯ python -c 'import sklearn.metrics'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/__init__.py", line 7, in <module>
    from . import cluster
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/cluster/__init__.py", line 25, in <module>
    from ._unsupervised import (
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/cluster/_unsupervised.py", line 23, in <module>
    from ..pairwise import _VALID_METRICS, pairwise_distances, pairwise_distances_chunked
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/pairwise.py", line 43, in <module>
    from ._pairwise_distances_reduction import ArgKmin
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/__init__.py", line 94, in <module>
    from ._dispatcher import (
  File "/home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/_dispatcher.py", line 17, in <module>
    from ._argkmin_classmode import (
ImportError: /home/lesteve/micromamba/envs/del/lib/python3.12/site-packages/sklearn/metrics/_pairwise_distances_reduction/_argkmin_classmode.cpython-312-x86_64-linux-gnu.so: undefined symbol: _ZdlPv
```

COMMENT:
`_ZdlPv` corresponds to the delete operator.

C++14 introduced sized delete operators (see [`(5)` `(6)` in this list](https://en.cppreference.com/w/cpp/memory/new/operator_delete)).

I think we might be in the case mentioned by [the "Backwards compatibility" section of the C++ Sized Deallocation Proposal](https://isocpp.org/files/papers/n3778.html#Compatibility):

> New programs using the sized version linking against an old system allocation library would fail to link. This can be fixed with the addition of a small shim, in which a sized version simply forwards to the unsized version. Likewise with new binaries linked against a new application allocation library. 

More specifically, it might be that a shared library of `libstdc++` whose version does not include the associated symbol (e.g. for compiled extensions which requires C++11 only) is loaded, causing this symbol to be missing when `_argkmin_classmode` is being loaded.

Labels: Bug, Build / CI
Macro vs micro-averaging switched up in user guide

### Describe the issue linked to the documentation

Hi guys,
In the "ROC curve using micro-averaged OvR" part of the doc (https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#roc-curve-using-micro-averaged-ovr)

it says:
"In a multi-class classification setup with highly imbalanced classes, micro-averaging is preferable over macro-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here."

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

If correct, I believe it could spare users some confusion. Thanks for all your work, Im just trying to help :) !!!

### Suggest a potential alternative/fix

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

COMMENT:
cc @ogrisel @lorentzenchr @GaelVaroquaux who might have a better intuition here.

Labels: Documentation
Macro vs micro-averaging switched up in user guide

### Describe the issue linked to the documentation

Hi guys,
In the "ROC curve using micro-averaged OvR" part of the doc (https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#roc-curve-using-micro-averaged-ovr)

it says:
"In a multi-class classification setup with highly imbalanced classes, micro-averaging is preferable over macro-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here."

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

If correct, I believe it could spare users some confusion. Thanks for all your work, Im just trying to help :) !!!

### Suggest a potential alternative/fix

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

COMMENT:
@uhoenig You are right.

In micro averaging, all examples are treated equally (we compare predictions and ground truth for each example and compute the necessary metrics), while for macro averaging all classes are treated equally (we compare prediction and ground truth of examples for each class, compute the metrics for each class, and average those class metrics to get the macro average). See [slide 41](https://sebastianraschka.com/pdf/lecture-notes/stat451fs20/12_eval5-metrics__slides.pdf).

As such, in a multi-class setting with imbalanced classes, if the overall performance of a classifier is important to us, we should opt for macro-based evaluation.

On that note, it seems that few sentences above it should also be macro instead of micro:
> Micro-averaging aggregates the contributions from all the classes (using [numpy.ravel](https://numpy.org/doc/stable/reference/generated/numpy.ravel.html#numpy.ravel)) to compute the average metrics as follows:

should be
> **Macro**-averaging aggregates the contributions from all the classes (using [numpy.ravel](https://numpy.org/doc/stable/reference/generated/numpy.ravel.html#numpy.ravel)) to compute the average metrics as follows:

Labels: Documentation
Macro vs micro-averaging switched up in user guide

### Describe the issue linked to the documentation

Hi guys,
In the "ROC curve using micro-averaged OvR" part of the doc (https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#roc-curve-using-micro-averaged-ovr)

it says:
"In a multi-class classification setup with highly imbalanced classes, micro-averaging is preferable over macro-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here."

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

If correct, I believe it could spare users some confusion. Thanks for all your work, Im just trying to help :) !!!

### Suggest a potential alternative/fix

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

COMMENT:
Micro-average works will aggregate all instances (samples from all classes) to compute the metric. So a data point from a "minority" or "majority" class will have the same impact.

Macro-average will group sample by class and aggregate (using the mean) afterwards. Therefore, you increase the importance of data points from under-represented classes because you consider them as important of highly populated classes.

Having these aspects in mind, I cannot tell that one metric is particularly better than the other; it all boils down of the application and the setup where the classifier will be used.

Labels: Documentation
Macro vs micro-averaging switched up in user guide

### Describe the issue linked to the documentation

Hi guys,
In the "ROC curve using micro-averaged OvR" part of the doc (https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#roc-curve-using-micro-averaged-ovr)

it says:
"In a multi-class classification setup with highly imbalanced classes, micro-averaging is preferable over macro-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here."

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

If correct, I believe it could spare users some confusion. Thanks for all your work, Im just trying to help :) !!!

### Suggest a potential alternative/fix

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

COMMENT:
I assume that we should just remove the statement and instead make it explicit what are the consequence to use one or another type of average.

Labels: Documentation
Macro vs micro-averaging switched up in user guide

### Describe the issue linked to the documentation

Hi guys,
In the "ROC curve using micro-averaged OvR" part of the doc (https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#roc-curve-using-micro-averaged-ovr)

it says:
"In a multi-class classification setup with highly imbalanced classes, micro-averaging is preferable over macro-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here."

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

If correct, I believe it could spare users some confusion. Thanks for all your work, Im just trying to help :) !!!

### Suggest a potential alternative/fix

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

COMMENT:
> Having these aspects in mind, I cannot tell that one metric is particularly better than the other; it all boils down of the application and the setup where the classifier will be used.

Yes, indeed.

Labels: Documentation
Macro vs micro-averaging switched up in user guide

### Describe the issue linked to the documentation

Hi guys,
In the "ROC curve using micro-averaged OvR" part of the doc (https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#roc-curve-using-micro-averaged-ovr)

it says:
"In a multi-class classification setup with highly imbalanced classes, micro-averaging is preferable over macro-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here."

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

If correct, I believe it could spare users some confusion. Thanks for all your work, Im just trying to help :) !!!

### Suggest a potential alternative/fix

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

COMMENT:
> On that note, it seems that few sentences above it should also be macro instead of micro:
> 
>     Micro-averaging aggregates the contributions from all the classes (using numpy.ravel) to compute the average metrics as follows:
> 
> should be
>
>     Macro-averaging aggregates the contributions from all the classes (using numpy.ravel) to compute the average metrics as follows:

It seems you're right: macro-averaging does class-level averaging (this is why it's called macro), and micro-averaging does instance-level averaging.

Labels: Documentation
Macro vs micro-averaging switched up in user guide

### Describe the issue linked to the documentation

Hi guys,
In the "ROC curve using micro-averaged OvR" part of the doc (https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#roc-curve-using-micro-averaged-ovr)

it says:
"In a multi-class classification setup with highly imbalanced classes, micro-averaging is preferable over macro-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here."

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

If correct, I believe it could spare users some confusion. Thanks for all your work, Im just trying to help :) !!!

### Suggest a potential alternative/fix

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

COMMENT:
I'd love to contribute to this issue. It may also be worth mentioning that in a multi-class classification setup with balanced classes, both macro and micro averaging could produce comparable results when evaluating ROC curves (as can be seen for the Iris plants dataset in the documentation).

Labels: Documentation
Macro vs micro-averaging switched up in user guide

### Describe the issue linked to the documentation

Hi guys,
In the "ROC curve using micro-averaged OvR" part of the doc (https://scikit-learn.org/stable/auto_examples/model_selection/plot_roc.html#roc-curve-using-micro-averaged-ovr)

it says:
"In a multi-class classification setup with highly imbalanced classes, micro-averaging is preferable over macro-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here."

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

If correct, I believe it could spare users some confusion. Thanks for all your work, Im just trying to help :) !!!

### Suggest a potential alternative/fix

I believe it should say: 
In a multi-class classification setup with highly imbalanced classes, **macro**-averaging is preferable over **micro**-averaging. In such cases, one can alternatively use a weighted macro-averaging, not demoed here.

COMMENT:
I appreciate the discussion regarding the documentation on micro and macro averaging for classification in multiclass scenarios. I concur with glemaitre's viewpoint on neutrally explaining the effects of choosing either averaging method, as it allows users to make informed decisions based on their specific needs without swaying them towards one option.

However, I would like to emphasize the value of providing guidance, particularly regarding handling imbalanced datasets. Real-world datasets are seldom perfectly balanced, making tips on effective strategies—like this library provides for: stratified sampling, class weighting, and the appropriate use of macro averaging in multiclass settings—not just useful but crucial for achieving reliable results. These recommendations align with the library's consistent efforts to equip users to tackle imbalanced classes effectively.

Removing explicit statements about the superiority of one method over another is sensible. Yet, maintaining practical advice reflects the realities users face and supports the library's broader goal of fostering effective and informed machine learning practices.

Labels: Documentation