Talip7/scikit-learn-issues-multilabel huggingface dataset:
BUG (likely): DBSCAN producing strange results on a geographical dataset

### Describe the bug

The issue has been described under this StackOverflow question: [https://stackoverflow.com/questions/76774329/dbscan-producing-strange-results-on-a-ships-location-dataset](https://stackoverflow.com/questions/76774329/dbscan-producing-strange-results-on-a-ships-location-dataset)

The dataset: https://pastebin.pl/view/86b44fe9 

### Steps/Code to Reproduce

```python
from sklearn.cluster import DBSCAN

file = open("86b44fe9.txt", "r")
lines = file.readlines()
x = []
for p in lines:
    poi = p.rstrip("\n").split(" ")
    x.append([float(poi[2]), float(poi[3])])

# Parameters of DBSCAN
min_samples = 42
eps = 0.001 

dbscan = DBSCAN(eps, min_samples).fit(x) # fitting the model
labels = dbscan.labels_

out_file = open("clusters.txt", "w")    
for p in range(len(lines)):
    poi = lines[p].rstrip("\n").split(" ")
    out_file.write(poi[0] + " ")
    out_file.write(poi[1] + " ")
    out_file.write(str(labels[p]))
    out_file.write("\n")
    
out_file.close()
```

### Expected Results

The detected anomalies highlighted in red in the [StackOverflow question](https://stackoverflow.com/questions/76774329/dbscan-producing-strange-results-on-a-ships-location-dataset) (e.g. the one having an id of 10248558 should not be considered as an outlier).

### Actual Results

The clusters.txt reports the actual results.

### Versions

```shell
System:
    python: 3.8.3 (default, Jul  2 2020, 17:30:36) [MSC v.1916 64 bit (AMD64)]
executable: C:\Users\banbar\anaconda3\python.exe
   machine: Windows-10-10.0.19041-SP0

Python dependencies:
          pip: 20.1.1
   setuptools: 49.2.0.post20200714
      sklearn: 0.23.1
        numpy: 1.23.5
        scipy: 1.10.1
       Cython: 0.29.21
       pandas: 1.0.5
   matplotlib: 3.2.2
       joblib: 0.16.0
threadpoolctl: 2.1.0

Built with OpenMP: True
```

COMMENT:
w/o a small reproducible I'm afraid we can't move on, and we shouldn't be downloading datasets from the web to debug issues. Closing for now, happy to re-open when a small reproducible is available.

Labels: Bug, module:cluster, Needs Reproducible Code
Add leaky_relu to Neural Network

### Describe the workflow you want to enable

I would like to use the leaky_relu activation function with MLP Classifier , I thought it has already become quite popular due to its ability to be more robust to noise as compared to relu & avoid the dying relu problem. I think we should consider implementing it in sklearn.nn . I'm willing to implement this.

### Describe your proposed solution

`import numpy as np

def leaky_relu(x):
    return np.where(x > 0, x, 0.01 * x)`

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

None

### Additional context

None

COMMENT:
@aadya940 Thanks fo the proposal.
From https://scikit-learn.org/stable/faq.html#why-is-there-no-support-for-deep-or-reinforcement-learning-will-there-be-support-for-deep-or-reinforcement-learning-in-scikit-learn:
> Note that scikit-learn currently implements a simple multilayer perceptron in [sklearn.neural_network](https://scikit-learn.org/stable/modules/classes.html#module-sklearn.neural_network). We will only accept bug fixes for this module. If you want to implement more complex deep learning models, please turn to popular deep learning frameworks such as [tensorflow](https://www.tensorflow.org/), [keras](https://keras.io/) and [pytorch](https://pytorch.org/).

Labels: New Feature, Needs Triage
DOC Remove some links from the list of related packages

From the list https://scikit-learn.org/stable/related_projects.html, I propose to remove
- svmlight-loader
  Reason: Not installable via `pip install`, not license
- Neptune because it is not really usable without an account. Was added in #20767.
- rep
  Reason: outdated (last commit in 2016), requires `scikit-learn == 0.17.1`
- nolearn
  Reason: outdated (last commit in 2019), requires `scikit-learn==0.17`
- Lasagne: outdated
- Kernel Regression
  Reason: outdated
- LibOPF
  Reason: not installable via `pip install`
- Spotlight
  Reason: not installable via `pip install` or `conda install` (only some non-standard channel)
- MSMBuilder
  Reason: [github repo](https://github.com/msmbuilder/msmbuilder) has been archived

Remarks:
- mlxtend is listed twice
- LightGBM should be listed

BTW: We should set some standard as to what we require to be listed.

COMMENT:
I agree with all the points except Neptune. Most recent experiment trackers I've seen, such as Neptune, Weights and Bias, Iterative Studio, CometML, etc, all require an account so that your metrics & results can be stored somewhere. We either do not list any hosted experiment trackers or be okay with the account requirement.

Labels: Documentation
DOC Remove some links from the list of related packages

From the list https://scikit-learn.org/stable/related_projects.html, I propose to remove
- svmlight-loader
  Reason: Not installable via `pip install`, not license
- Neptune because it is not really usable without an account. Was added in #20767.
- rep
  Reason: outdated (last commit in 2016), requires `scikit-learn == 0.17.1`
- nolearn
  Reason: outdated (last commit in 2019), requires `scikit-learn==0.17`
- Lasagne: outdated
- Kernel Regression
  Reason: outdated
- LibOPF
  Reason: not installable via `pip install`
- Spotlight
  Reason: not installable via `pip install` or `conda install` (only some non-standard channel)
- MSMBuilder
  Reason: [github repo](https://github.com/msmbuilder/msmbuilder) has been archived

Remarks:
- mlxtend is listed twice
- LightGBM should be listed

BTW: We should set some standard as to what we require to be listed.

COMMENT:
I am pretty OK with the removal and don't have a strong opinion of the point raised by @thomasjpfan. Either way is fine with me.

Since we are editing this file, I would also revise the `hdbscan` line to cross-reference our implementation and the same with `TargetEncoder` for `categorical-encoder`. I would probably do the same with the `xgboost` and `lightgdbm` and the `HistGradientBoosting` model.

I would also remove `keras` because I don't think they have a scikit-learn interface (I did not check Keras 3.0) and it was the reason to have `scikeras`, isn't it?

I would probably regroup `tslearn`, `sktime` and `skforecast` under a time-series section.

Labels: Documentation
DOC Remove some links from the list of related packages

From the list https://scikit-learn.org/stable/related_projects.html, I propose to remove
- svmlight-loader
  Reason: Not installable via `pip install`, not license
- Neptune because it is not really usable without an account. Was added in #20767.
- rep
  Reason: outdated (last commit in 2016), requires `scikit-learn == 0.17.1`
- nolearn
  Reason: outdated (last commit in 2019), requires `scikit-learn==0.17`
- Lasagne: outdated
- Kernel Regression
  Reason: outdated
- LibOPF
  Reason: not installable via `pip install`
- Spotlight
  Reason: not installable via `pip install` or `conda install` (only some non-standard channel)
- MSMBuilder
  Reason: [github repo](https://github.com/msmbuilder/msmbuilder) has been archived

Remarks:
- mlxtend is listed twice
- LightGBM should be listed

BTW: We should set some standard as to what we require to be listed.

COMMENT:
> I would also remove keras because I don't think they have a scikit-learn interface (I did not check Keras 3.0) and it was the reason to have scikeras, isn't it?

The link already directs to the `tensorflow.keras`. From what I read in https://www.tensorflow.org/api_docs/python/tf/keras/Model, it seems fine to keep this entry.

Labels: Documentation
⚠️ CI failed on macOS.pylatest_conda_forge_mkl ⚠️

**CI is still failing on [macOS.pylatest_conda_forge_mkl](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=58914&view=logs&j=97641769-79fb-5590-9088-a30ce9b850b9)** (Sep 12, 2023)
- test_pairwise_distances_argkmin[45-float32-parallel_on_X-cityblock-0-500]
- test_pairwise_distances_argkmin[45-float32-parallel_on_Y-cityblock-0-500]

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=59180&view=logs&j=97641769-79fb-5590-9088-a30ce9b850b9) on Sep 15, 2023

Labels: Needs Triage
⚠️ CI failed on macOS.pylatest_conda_forge_mkl ⚠️

**CI is still failing on [macOS.pylatest_conda_forge_mkl](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=58914&view=logs&j=97641769-79fb-5590-9088-a30ce9b850b9)** (Sep 12, 2023)
- test_pairwise_distances_argkmin[45-float32-parallel_on_X-cityblock-0-500]
- test_pairwise_distances_argkmin[45-float32-parallel_on_Y-cityblock-0-500]

COMMENT:
It is handled in another issue.

Labels: Needs Triage
OneHotEncoder linter issues on argument typing

### Describe the bug

The pyright lsp flags type warnings when a OneHotEncoder is initialized with categories as a list and/or dtype specified as anything but np.float64. Code runs fine, so this maybe should not be considered a bug. It is just a slight annoyance. 

### Steps/Code to Reproduce

```
from sklearn.preprocessing import OneHotEncoder

categories = [["a", "b"]]

ohe = OneHotEncoder(categories=categories, dtype=bool)
```

### Expected Results

The documentation indicates that **categories** can be a str="auto" or list and **dtype** appears to be handled downstream by numpy, but the default is initialized as np.float64 and this is somehow confusing the lsp. 

### Actual Results

```
Argument of type "list[list[str]]" cannot be assigned to parameter "categories" of type "str" in function "__init__" Pyright (reportGeneralTypeIssues) [5, 32]
 │        "list[list[str]]" is incompatible with "str" 
 │       Argument of type "type[bool]" cannot be assigned to parameter "dtype" of type "float64" in function "__init__" Pyright (reportGeneralTypeIssues) [5, 50]
 │        "type[bool]" is incompatible with "float64" 
 │        Type "type[bool]" cannot be assigned to type "float64"
```
### Versions

```shell
System:
    python: 3.11.4 | packaged by conda-forge | (main, Jun 10 2023, 18:08:17) [GCC 12.2.0]
executable: /home/scott/mambaforge/envs/sklearn_new/bin/python
   machine: Linux-6.4.4-zen1-1-zen-x86_64-with-glibc2.37

Python dependencies:
      sklearn: 1.2.2
          pip: 23.2.1
   setuptools: 68.0.0
        numpy: 1.23.5
        scipy: 1.10.1
       Cython: None
       pandas: 2.0.2
   matplotlib: 3.2.2
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /home/scott/.local/lib/python3.11/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
    num_threads: 12

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/scott/.local/lib/python3.11/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 12

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/scott/.local/lib/python3.11/site-packages/scipy.libs/libopenblasp-r0-41284840.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell
    num_threads: 12
```

COMMENT:
I believe categories[i] in the docstring should return a list of categories for column i. So a 2-D list is expected. If one tries with a 1-D list the error:

```ValueError: Shape mismatch: if categories is an array, it has to be of shape (n_features,)```

is raised, which is consistent with this interpretation.

Labels: Bug, Needs Triage
OneHotEncoder linter issues on argument typing

### Describe the bug

The pyright lsp flags type warnings when a OneHotEncoder is initialized with categories as a list and/or dtype specified as anything but np.float64. Code runs fine, so this maybe should not be considered a bug. It is just a slight annoyance. 

### Steps/Code to Reproduce

```
from sklearn.preprocessing import OneHotEncoder

categories = [["a", "b"]]

ohe = OneHotEncoder(categories=categories, dtype=bool)
```

### Expected Results

The documentation indicates that **categories** can be a str="auto" or list and **dtype** appears to be handled downstream by numpy, but the default is initialized as np.float64 and this is somehow confusing the lsp. 

### Actual Results

```
Argument of type "list[list[str]]" cannot be assigned to parameter "categories" of type "str" in function "__init__" Pyright (reportGeneralTypeIssues) [5, 32]
 │        "list[list[str]]" is incompatible with "str" 
 │       Argument of type "type[bool]" cannot be assigned to parameter "dtype" of type "float64" in function "__init__" Pyright (reportGeneralTypeIssues) [5, 50]
 │        "type[bool]" is incompatible with "float64" 
 │        Type "type[bool]" cannot be assigned to type "float64"
```
### Versions

```shell
System:
    python: 3.11.4 | packaged by conda-forge | (main, Jun 10 2023, 18:08:17) [GCC 12.2.0]
executable: /home/scott/mambaforge/envs/sklearn_new/bin/python
   machine: Linux-6.4.4-zen1-1-zen-x86_64-with-glibc2.37

Python dependencies:
      sklearn: 1.2.2
          pip: 23.2.1
   setuptools: 68.0.0
        numpy: 1.23.5
        scipy: 1.10.1
       Cython: None
       pandas: 2.0.2
   matplotlib: 3.2.2
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /home/scott/.local/lib/python3.11/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
    num_threads: 12

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/scott/.local/lib/python3.11/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 12

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/scott/.local/lib/python3.11/site-packages/scipy.libs/libopenblasp-r0-41284840.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell
    num_threads: 12
```

COMMENT:
```
from sklearn.preprocessing import OneHotEncoder
ohe = OneHotEncoder(categories=[["a","b"]],dtype=bool)

X = [["a"], ["b"], ["a"]]

tmp = ohe.fit_transform(X)
print(tmp)
```
### Output
```
(0, 0)        True
(1, 1)        True
(2, 0)        True
```
I could not reproduce error message

Labels: Bug, Needs Triage
OneHotEncoder linter issues on argument typing

### Describe the bug

The pyright lsp flags type warnings when a OneHotEncoder is initialized with categories as a list and/or dtype specified as anything but np.float64. Code runs fine, so this maybe should not be considered a bug. It is just a slight annoyance. 

### Steps/Code to Reproduce

```
from sklearn.preprocessing import OneHotEncoder

categories = [["a", "b"]]

ohe = OneHotEncoder(categories=categories, dtype=bool)
```

### Expected Results

The documentation indicates that **categories** can be a str="auto" or list and **dtype** appears to be handled downstream by numpy, but the default is initialized as np.float64 and this is somehow confusing the lsp. 

### Actual Results

```
Argument of type "list[list[str]]" cannot be assigned to parameter "categories" of type "str" in function "__init__" Pyright (reportGeneralTypeIssues) [5, 32]
 │        "list[list[str]]" is incompatible with "str" 
 │       Argument of type "type[bool]" cannot be assigned to parameter "dtype" of type "float64" in function "__init__" Pyright (reportGeneralTypeIssues) [5, 50]
 │        "type[bool]" is incompatible with "float64" 
 │        Type "type[bool]" cannot be assigned to type "float64"
```
### Versions

```shell
System:
    python: 3.11.4 | packaged by conda-forge | (main, Jun 10 2023, 18:08:17) [GCC 12.2.0]
executable: /home/scott/mambaforge/envs/sklearn_new/bin/python
   machine: Linux-6.4.4-zen1-1-zen-x86_64-with-glibc2.37

Python dependencies:
      sklearn: 1.2.2
          pip: 23.2.1
   setuptools: 68.0.0
        numpy: 1.23.5
        scipy: 1.10.1
       Cython: None
       pandas: 2.0.2
   matplotlib: 3.2.2
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /home/scott/.local/lib/python3.11/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
    num_threads: 12

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/scott/.local/lib/python3.11/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: Haswell
    num_threads: 12

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/scott/.local/lib/python3.11/site-packages/scipy.libs/libopenblasp-r0-41284840.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell
    num_threads: 12
```

COMMENT:
We do not maintain the typing hints that pyright uses. The typing information is from:

https://github.com/microsoft/python-type-stubs/blob/1add73961cc8251a8b2dad5e46ee8d78a9f260f8/stubs/sklearn/preprocessing/_encoders.pyi#L48

If the types are not consistent with the runtime behavior, then I recommend opening at issue in https://github.com/microsoft/python-type-stubs

Labels: Bug, Needs Triage
Balanced Accuracy Score is NOT equal to Recall Score

### Describe the bug

By definition balanced accuracy should be equal to recall averaged over all the classes. Current implementation gives different answers. Please see the example below. 

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

skm.recall_score(y_true, y_pred, average='macro')  # 0.25
skm.balanced_accuracy_score(y_true, y_pred)  # 0.5

```

### Steps/Code to Reproduce

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

recall = skm.recall_score(y_true, y_pred, average='macro')  
balanced_acc = skm.balanced_accuracy_score(y_true, y_pred) 
```

### Expected Results

```
recall = balaced_acc = 0.25
```

### Actual Results

```
recall = 0.25
balanced_acc = 0.5
```

### Versions

```shell
import sklearn; sklearn.show_versions()
```

COMMENT:
This is due to this line of code:

https://github.com/scikit-learn/scikit-learn/blob/d991a196cbecac251cc27f83144bd3f83d4c05f4/sklearn/metrics/_classification.py#L2388C30-L2388C30

It deletes all the `nan` accuracy in the `per_class`. 

Another interesting example to try:
y_true = [1]*100
y_pred = [for i in range(1, 101)]

balanced_accuracy_score(y_true, y_pred) = 0.01
recall_score(y_true, y_pred, average='macro') = 0.0001

Labels: Bug, New Feature
Balanced Accuracy Score is NOT equal to Recall Score

### Describe the bug

By definition balanced accuracy should be equal to recall averaged over all the classes. Current implementation gives different answers. Please see the example below. 

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

skm.recall_score(y_true, y_pred, average='macro')  # 0.25
skm.balanced_accuracy_score(y_true, y_pred)  # 0.5

```

### Steps/Code to Reproduce

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

recall = skm.recall_score(y_true, y_pred, average='macro')  
balanced_acc = skm.balanced_accuracy_score(y_true, y_pred) 
```

### Expected Results

```
recall = balaced_acc = 0.25
```

### Actual Results

```
recall = 0.25
balanced_acc = 0.5
```

### Versions

```shell
import sklearn; sklearn.show_versions()
```

COMMENT:
Adding on @msxingpeng remark, we don't have the handling of `zero_division`. Basically, on this corner case, the metrics are not equal. We could add the `zero_division` parameter to make `balanced_accuracy` consistent.

Labels: Bug, New Feature
Balanced Accuracy Score is NOT equal to Recall Score

### Describe the bug

By definition balanced accuracy should be equal to recall averaged over all the classes. Current implementation gives different answers. Please see the example below. 

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

skm.recall_score(y_true, y_pred, average='macro')  # 0.25
skm.balanced_accuracy_score(y_true, y_pred)  # 0.5

```

### Steps/Code to Reproduce

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

recall = skm.recall_score(y_true, y_pred, average='macro')  
balanced_acc = skm.balanced_accuracy_score(y_true, y_pred) 
```

### Expected Results

```
recall = balaced_acc = 0.25
```

### Actual Results

```
recall = 0.25
balanced_acc = 0.5
```

### Versions

```shell
import sklearn; sklearn.show_versions()
```

COMMENT:
It seems like there should be an epic where `zero_division` parameter will be added to all the metrics with some form of division, since issues regarding this behavior is on the rise lately.

Labels: Bug, New Feature
Balanced Accuracy Score is NOT equal to Recall Score

### Describe the bug

By definition balanced accuracy should be equal to recall averaged over all the classes. Current implementation gives different answers. Please see the example below. 

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

skm.recall_score(y_true, y_pred, average='macro')  # 0.25
skm.balanced_accuracy_score(y_true, y_pred)  # 0.5

```

### Steps/Code to Reproduce

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

recall = skm.recall_score(y_true, y_pred, average='macro')  
balanced_acc = skm.balanced_accuracy_score(y_true, y_pred) 
```

### Expected Results

```
recall = balaced_acc = 0.25
```

### Actual Results

```
recall = 0.25
balanced_acc = 0.5
```

### Versions

```shell
import sklearn; sklearn.show_versions()
```

COMMENT:
I am working on this issue .

Labels: Bug, New Feature
Balanced Accuracy Score is NOT equal to Recall Score

### Describe the bug

By definition balanced accuracy should be equal to recall averaged over all the classes. Current implementation gives different answers. Please see the example below. 

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

skm.recall_score(y_true, y_pred, average='macro')  # 0.25
skm.balanced_accuracy_score(y_true, y_pred)  # 0.5

```

### Steps/Code to Reproduce

```
import scikit.metrics as skm

y_true = [1,1]
y_pred = [1,2]

recall = skm.recall_score(y_true, y_pred, average='macro')  
balanced_acc = skm.balanced_accuracy_score(y_true, y_pred) 
```

### Expected Results

```
recall = balaced_acc = 0.25
```

### Actual Results

```
recall = 0.25
balanced_acc = 0.5
```

### Versions

```shell
import sklearn; sklearn.show_versions()
```

COMMENT:
Working on it !

Labels: Bug, New Feature
Putting it all together Pipelining is not working ( missing dependencies and plot )

### Describe the issue linked to the documentation

From https://scikit-learn.org/stable/tutorial/statistical_inference/putting_together.html#pipelining it is missing
```
from sklearn import datasets
import numpy as np
import matplotlib.pyplot as plt
```
The last chart is missing the data

![image](https://github.com/scikit-learn/scikit-learn/assets/687311/99953518-cc6e-4a63-a1a8-b15eda3363f4)


### Suggest a potential alternative/fix

_No response_

COMMENT:
Hi @diegolovison, it seems that some code has gone missing in your notebook. 
Were you using JupyterLight? It saves your prior modifications as cookies. What happens if you delete them?

Labels: Documentation