Talip7/scikit-learn-issues-multilabel huggingface dataset:
Path to adopt 32-bit implementations for `{KD, Ball}Tree`

## Motivation
Having and using 32-bit implementations of `{KD, Ball}Tree` allows for better preservation of dtype, lower memory footprint, and more consistent Cython code.

## Strategy
Work has already been started in #25914 to add the code for the new 32-bit implementations. These will not be directly used yet, and the PR instead focuses on the actual creation of the new classes. Consequently, `{KD, Ball}Tree` are bound to `{KD, Ball}Tree64` for consistency and backwards compatibility.

Following this PR, we will need to begin an API deprecation to move users away from constructing trees directly, and instead using a factory method (similar to `DistanceMetric.get_metric`). Then, later, we can separate `{KD, Ball}Tree` from `{KD, Ball}Tree64` so that we have a singular dispatcher `{KD, Ball}Tree` and two type-specialized implementations. 

The deprecation process involves:
1. Introducing `get_tree(...)` to `{KD, Ball}Tree64` with the same signature of `BinaryTree.__init__`, which is in charge of constructing the type-specialized trees directly.
2. Adding a `FutureWarning` to `BinaryTree.__init__` to begin deprecation, and suppressing the warning using a context manager in `{KD, Ball}Tree64.get_tree` to enforce it as the "correct" way to construct the trees.
3. **Complete the deprecation** by introducing a separate `{KD, Ball}Tree` into the hierarchy which comes with the same `get_tree` method and fully remove the `FutureWarning` from `{KD, Ball}Tree{32, 64}.__init__` since they should no longer be directly constructed, as well as getting rid of the `{KD, Ball}Tree{32, 64}.get_tree` method since it should only exist in `{KD, Ball}Tree`.

At the end, the expected API is:
```python
from sklearn.neighbors import KDTree

# Data
X = ...

# tree is thus an instance of KDTree{32, 64} based on X.dtype
tree = KDTree.get_tree(X, ...)
```

cc: @thomasjpfan @jjerphan @OmarManzoor

COMMENT:
Hi @OmarManzoor,

I do not have time to think of it in details for now, but I do want to block.

You might want to start an implementation, but it might be further discussed (for instance I do not think we want to deprecate the current way we create `{KD,Ball}Tree` because we need to maintain backward compatibility).

Labels: API, Needs Decision, RFC
Path to adopt 32-bit implementations for `{KD, Ball}Tree`

## Motivation
Having and using 32-bit implementations of `{KD, Ball}Tree` allows for better preservation of dtype, lower memory footprint, and more consistent Cython code.

## Strategy
Work has already been started in #25914 to add the code for the new 32-bit implementations. These will not be directly used yet, and the PR instead focuses on the actual creation of the new classes. Consequently, `{KD, Ball}Tree` are bound to `{KD, Ball}Tree64` for consistency and backwards compatibility.

Following this PR, we will need to begin an API deprecation to move users away from constructing trees directly, and instead using a factory method (similar to `DistanceMetric.get_metric`). Then, later, we can separate `{KD, Ball}Tree` from `{KD, Ball}Tree64` so that we have a singular dispatcher `{KD, Ball}Tree` and two type-specialized implementations. 

The deprecation process involves:
1. Introducing `get_tree(...)` to `{KD, Ball}Tree64` with the same signature of `BinaryTree.__init__`, which is in charge of constructing the type-specialized trees directly.
2. Adding a `FutureWarning` to `BinaryTree.__init__` to begin deprecation, and suppressing the warning using a context manager in `{KD, Ball}Tree64.get_tree` to enforce it as the "correct" way to construct the trees.
3. **Complete the deprecation** by introducing a separate `{KD, Ball}Tree` into the hierarchy which comes with the same `get_tree` method and fully remove the `FutureWarning` from `{KD, Ball}Tree{32, 64}.__init__` since they should no longer be directly constructed, as well as getting rid of the `{KD, Ball}Tree{32, 64}.get_tree` method since it should only exist in `{KD, Ball}Tree`.

At the end, the expected API is:
```python
from sklearn.neighbors import KDTree

# Data
X = ...

# tree is thus an instance of KDTree{32, 64} based on X.dtype
tree = KDTree.get_tree(X, ...)
```

cc: @thomasjpfan @jjerphan @OmarManzoor

COMMENT:
@jjerphan I think in that case we can wait before the discussion regarding this is finalized. Thanks for mentioning.

Labels: API, Needs Decision, RFC
Path to adopt 32-bit implementations for `{KD, Ball}Tree`

## Motivation
Having and using 32-bit implementations of `{KD, Ball}Tree` allows for better preservation of dtype, lower memory footprint, and more consistent Cython code.

## Strategy
Work has already been started in #25914 to add the code for the new 32-bit implementations. These will not be directly used yet, and the PR instead focuses on the actual creation of the new classes. Consequently, `{KD, Ball}Tree` are bound to `{KD, Ball}Tree64` for consistency and backwards compatibility.

Following this PR, we will need to begin an API deprecation to move users away from constructing trees directly, and instead using a factory method (similar to `DistanceMetric.get_metric`). Then, later, we can separate `{KD, Ball}Tree` from `{KD, Ball}Tree64` so that we have a singular dispatcher `{KD, Ball}Tree` and two type-specialized implementations. 

The deprecation process involves:
1. Introducing `get_tree(...)` to `{KD, Ball}Tree64` with the same signature of `BinaryTree.__init__`, which is in charge of constructing the type-specialized trees directly.
2. Adding a `FutureWarning` to `BinaryTree.__init__` to begin deprecation, and suppressing the warning using a context manager in `{KD, Ball}Tree64.get_tree` to enforce it as the "correct" way to construct the trees.
3. **Complete the deprecation** by introducing a separate `{KD, Ball}Tree` into the hierarchy which comes with the same `get_tree` method and fully remove the `FutureWarning` from `{KD, Ball}Tree{32, 64}.__init__` since they should no longer be directly constructed, as well as getting rid of the `{KD, Ball}Tree{32, 64}.get_tree` method since it should only exist in `{KD, Ball}Tree`.

At the end, the expected API is:
```python
from sklearn.neighbors import KDTree

# Data
X = ...

# tree is thus an instance of KDTree{32, 64} based on X.dtype
tree = KDTree.get_tree(X, ...)
```

cc: @thomasjpfan @jjerphan @OmarManzoor

COMMENT:
Thinking again, I do not want to have the decision be pending for an eternity since we might not be able to discuss it in the coming weeks (at least I might not be and in this case I do not want to cookie lick it).

@OmarManzoor: you can implement the proposal of @thomasjpfan I think.

Labels: API, Needs Decision, RFC
Path to adopt 32-bit implementations for `{KD, Ball}Tree`

## Motivation
Having and using 32-bit implementations of `{KD, Ball}Tree` allows for better preservation of dtype, lower memory footprint, and more consistent Cython code.

## Strategy
Work has already been started in #25914 to add the code for the new 32-bit implementations. These will not be directly used yet, and the PR instead focuses on the actual creation of the new classes. Consequently, `{KD, Ball}Tree` are bound to `{KD, Ball}Tree64` for consistency and backwards compatibility.

Following this PR, we will need to begin an API deprecation to move users away from constructing trees directly, and instead using a factory method (similar to `DistanceMetric.get_metric`). Then, later, we can separate `{KD, Ball}Tree` from `{KD, Ball}Tree64` so that we have a singular dispatcher `{KD, Ball}Tree` and two type-specialized implementations. 

The deprecation process involves:
1. Introducing `get_tree(...)` to `{KD, Ball}Tree64` with the same signature of `BinaryTree.__init__`, which is in charge of constructing the type-specialized trees directly.
2. Adding a `FutureWarning` to `BinaryTree.__init__` to begin deprecation, and suppressing the warning using a context manager in `{KD, Ball}Tree64.get_tree` to enforce it as the "correct" way to construct the trees.
3. **Complete the deprecation** by introducing a separate `{KD, Ball}Tree` into the hierarchy which comes with the same `get_tree` method and fully remove the `FutureWarning` from `{KD, Ball}Tree{32, 64}.__init__` since they should no longer be directly constructed, as well as getting rid of the `{KD, Ball}Tree{32, 64}.get_tree` method since it should only exist in `{KD, Ball}Tree`.

At the end, the expected API is:
```python
from sklearn.neighbors import KDTree

# Data
X = ...

# tree is thus an instance of KDTree{32, 64} based on X.dtype
tree = KDTree.get_tree(X, ...)
```

cc: @thomasjpfan @jjerphan @OmarManzoor

COMMENT:
@adrinjalali @glemaitre @ogrisel Could you provide an opinion here in order to finalise this?

Labels: API, Needs Decision, RFC
Path to adopt 32-bit implementations for `{KD, Ball}Tree`

## Motivation
Having and using 32-bit implementations of `{KD, Ball}Tree` allows for better preservation of dtype, lower memory footprint, and more consistent Cython code.

## Strategy
Work has already been started in #25914 to add the code for the new 32-bit implementations. These will not be directly used yet, and the PR instead focuses on the actual creation of the new classes. Consequently, `{KD, Ball}Tree` are bound to `{KD, Ball}Tree64` for consistency and backwards compatibility.

Following this PR, we will need to begin an API deprecation to move users away from constructing trees directly, and instead using a factory method (similar to `DistanceMetric.get_metric`). Then, later, we can separate `{KD, Ball}Tree` from `{KD, Ball}Tree64` so that we have a singular dispatcher `{KD, Ball}Tree` and two type-specialized implementations. 

The deprecation process involves:
1. Introducing `get_tree(...)` to `{KD, Ball}Tree64` with the same signature of `BinaryTree.__init__`, which is in charge of constructing the type-specialized trees directly.
2. Adding a `FutureWarning` to `BinaryTree.__init__` to begin deprecation, and suppressing the warning using a context manager in `{KD, Ball}Tree64.get_tree` to enforce it as the "correct" way to construct the trees.
3. **Complete the deprecation** by introducing a separate `{KD, Ball}Tree` into the hierarchy which comes with the same `get_tree` method and fully remove the `FutureWarning` from `{KD, Ball}Tree{32, 64}.__init__` since they should no longer be directly constructed, as well as getting rid of the `{KD, Ball}Tree{32, 64}.get_tree` method since it should only exist in `{KD, Ball}Tree`.

At the end, the expected API is:
```python
from sklearn.neighbors import KDTree

# Data
X = ...

# tree is thus an instance of KDTree{32, 64} based on X.dtype
tree = KDTree.get_tree(X, ...)
```

cc: @thomasjpfan @jjerphan @OmarManzoor

COMMENT:
If I understand the issue correctly, I'd prefer what @thomasjpfan is suggesting. But I'm wondering how we'll move forward since @thomasjpfan , @Micky774 , and @jjerphan are all less available these days.

Labels: API, Needs Decision, RFC
Path to adopt 32-bit implementations for `{KD, Ball}Tree`

## Motivation
Having and using 32-bit implementations of `{KD, Ball}Tree` allows for better preservation of dtype, lower memory footprint, and more consistent Cython code.

## Strategy
Work has already been started in #25914 to add the code for the new 32-bit implementations. These will not be directly used yet, and the PR instead focuses on the actual creation of the new classes. Consequently, `{KD, Ball}Tree` are bound to `{KD, Ball}Tree64` for consistency and backwards compatibility.

Following this PR, we will need to begin an API deprecation to move users away from constructing trees directly, and instead using a factory method (similar to `DistanceMetric.get_metric`). Then, later, we can separate `{KD, Ball}Tree` from `{KD, Ball}Tree64` so that we have a singular dispatcher `{KD, Ball}Tree` and two type-specialized implementations. 

The deprecation process involves:
1. Introducing `get_tree(...)` to `{KD, Ball}Tree64` with the same signature of `BinaryTree.__init__`, which is in charge of constructing the type-specialized trees directly.
2. Adding a `FutureWarning` to `BinaryTree.__init__` to begin deprecation, and suppressing the warning using a context manager in `{KD, Ball}Tree64.get_tree` to enforce it as the "correct" way to construct the trees.
3. **Complete the deprecation** by introducing a separate `{KD, Ball}Tree` into the hierarchy which comes with the same `get_tree` method and fully remove the `FutureWarning` from `{KD, Ball}Tree{32, 64}.__init__` since they should no longer be directly constructed, as well as getting rid of the `{KD, Ball}Tree{32, 64}.get_tree` method since it should only exist in `{KD, Ball}Tree`.

At the end, the expected API is:
```python
from sklearn.neighbors import KDTree

# Data
X = ...

# tree is thus an instance of KDTree{32, 64} based on X.dtype
tree = KDTree.get_tree(X, ...)
```

cc: @thomasjpfan @jjerphan @OmarManzoor

COMMENT:
fwiw in about 1 month I should be available again to actually review PRs. I'm still unfunded, but I'll actually have breathing room for scikit-learn as a hobby again :)

Labels: API, Needs Decision, RFC
Path to adopt 32-bit implementations for `{KD, Ball}Tree`

## Motivation
Having and using 32-bit implementations of `{KD, Ball}Tree` allows for better preservation of dtype, lower memory footprint, and more consistent Cython code.

## Strategy
Work has already been started in #25914 to add the code for the new 32-bit implementations. These will not be directly used yet, and the PR instead focuses on the actual creation of the new classes. Consequently, `{KD, Ball}Tree` are bound to `{KD, Ball}Tree64` for consistency and backwards compatibility.

Following this PR, we will need to begin an API deprecation to move users away from constructing trees directly, and instead using a factory method (similar to `DistanceMetric.get_metric`). Then, later, we can separate `{KD, Ball}Tree` from `{KD, Ball}Tree64` so that we have a singular dispatcher `{KD, Ball}Tree` and two type-specialized implementations. 

The deprecation process involves:
1. Introducing `get_tree(...)` to `{KD, Ball}Tree64` with the same signature of `BinaryTree.__init__`, which is in charge of constructing the type-specialized trees directly.
2. Adding a `FutureWarning` to `BinaryTree.__init__` to begin deprecation, and suppressing the warning using a context manager in `{KD, Ball}Tree64.get_tree` to enforce it as the "correct" way to construct the trees.
3. **Complete the deprecation** by introducing a separate `{KD, Ball}Tree` into the hierarchy which comes with the same `get_tree` method and fully remove the `FutureWarning` from `{KD, Ball}Tree{32, 64}.__init__` since they should no longer be directly constructed, as well as getting rid of the `{KD, Ball}Tree{32, 64}.get_tree` method since it should only exist in `{KD, Ball}Tree`.

At the end, the expected API is:
```python
from sklearn.neighbors import KDTree

# Data
X = ...

# tree is thus an instance of KDTree{32, 64} based on X.dtype
tree = KDTree.get_tree(X, ...)
```

cc: @thomasjpfan @jjerphan @OmarManzoor

COMMENT:
@adrinjalali I think the actual code needed to accomplish this should not be much. Hopefully it shouldn't be hard to review.

Labels: API, Needs Decision, RFC
Agglomerative clustering training error for seuclidean/mahalanobis affinity and single linkage

### Describe the bug

When trying Agglomerative clustering model training with the affinity as 'seuclidean' or 'mahalanobis' and the linkage as 'single' the training fails. The same affinity values along with other linkage such as 'average' options executes for model training. There's no specification given for this issue. Also, in the code I can see the handling for the single linkage is different and there is some cython code which is not accessible.

### Steps/Code to Reproduce

```

from sklearn.cluster import AgglomerativeClustering
from sklearn.datasets import load_iris
model = AgglomerativeClustering(affinity='mahalanobis', linkage='average')
data = load_iris(as_frame=True)['data']
model.fit(data)

```

### Expected Results

No error should be thrown sig

### Actual Results

![image](https://github.com/scikit-learn/scikit-learn/assets/69189799/c3da5d93-b215-4fd8-8610-a4c8ce632f8d)


### Versions

```shell
System:
    python: 3.8.17 (default, Jul  5 2023, 21:04:15)  [GCC 11.2.0]
executable: /home/albint/miniconda3/envs/myenv/bin/python
   machine: Linux-5.15.0-78-generic-x86_64-with-glibc2.17

Python dependencies:
      sklearn: 1.3.0
          pip: 23.1.2
   setuptools: 67.8.0
        numpy: 1.24.4
        scipy: 1.10.1
       Cython: 3.0.0
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.1
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/numpy.libs/libopenblas64_p-r0-15028c96.3.21.so
        version: 0.3.21
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-41284840.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libgomp
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
```

COMMENT:
The other linkage implementations use ``scipy.cluster.hierarchy.linkage`` which calls ``pdist`` which has default values (in the validator) for the extra args required for seuclidean and mahalanobis. For consistency the right thing to do would be to catch these special metrics and provide the required keywords. In the longer term it may be worth looking into the ``get_metric`` function in ``DistanceMetric`` to make this more consistent.

Labels: Bug, help wanted
Agglomerative clustering training error for seuclidean/mahalanobis affinity and single linkage

### Describe the bug

When trying Agglomerative clustering model training with the affinity as 'seuclidean' or 'mahalanobis' and the linkage as 'single' the training fails. The same affinity values along with other linkage such as 'average' options executes for model training. There's no specification given for this issue. Also, in the code I can see the handling for the single linkage is different and there is some cython code which is not accessible.

### Steps/Code to Reproduce

```

from sklearn.cluster import AgglomerativeClustering
from sklearn.datasets import load_iris
model = AgglomerativeClustering(affinity='mahalanobis', linkage='average')
data = load_iris(as_frame=True)['data']
model.fit(data)

```

### Expected Results

No error should be thrown sig

### Actual Results

![image](https://github.com/scikit-learn/scikit-learn/assets/69189799/c3da5d93-b215-4fd8-8610-a4c8ce632f8d)


### Versions

```shell
System:
    python: 3.8.17 (default, Jul  5 2023, 21:04:15)  [GCC 11.2.0]
executable: /home/albint/miniconda3/envs/myenv/bin/python
   machine: Linux-5.15.0-78-generic-x86_64-with-glibc2.17

Python dependencies:
      sklearn: 1.3.0
          pip: 23.1.2
   setuptools: 67.8.0
        numpy: 1.24.4
        scipy: 1.10.1
       Cython: 3.0.0
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.1
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/numpy.libs/libopenblas64_p-r0-15028c96.3.21.so
        version: 0.3.21
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-41284840.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libgomp
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
```

COMMENT:
Hello ! I am new on GitHub and I would like to contribute.
I'll try to make a PR for the third problem pointed out by @Micky774

Labels: Bug, help wanted
Agglomerative clustering training error for seuclidean/mahalanobis affinity and single linkage

### Describe the bug

When trying Agglomerative clustering model training with the affinity as 'seuclidean' or 'mahalanobis' and the linkage as 'single' the training fails. The same affinity values along with other linkage such as 'average' options executes for model training. There's no specification given for this issue. Also, in the code I can see the handling for the single linkage is different and there is some cython code which is not accessible.

### Steps/Code to Reproduce

```

from sklearn.cluster import AgglomerativeClustering
from sklearn.datasets import load_iris
model = AgglomerativeClustering(affinity='mahalanobis', linkage='average')
data = load_iris(as_frame=True)['data']
model.fit(data)

```

### Expected Results

No error should be thrown sig

### Actual Results

![image](https://github.com/scikit-learn/scikit-learn/assets/69189799/c3da5d93-b215-4fd8-8610-a4c8ce632f8d)


### Versions

```shell
System:
    python: 3.8.17 (default, Jul  5 2023, 21:04:15)  [GCC 11.2.0]
executable: /home/albint/miniconda3/envs/myenv/bin/python
   machine: Linux-5.15.0-78-generic-x86_64-with-glibc2.17

Python dependencies:
      sklearn: 1.3.0
          pip: 23.1.2
   setuptools: 67.8.0
        numpy: 1.24.4
        scipy: 1.10.1
       Cython: 3.0.0
       pandas: 2.0.3
   matplotlib: 3.7.2
       joblib: 1.3.1
threadpoolctl: 3.2.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/numpy.libs/libopenblas64_p-r0-15028c96.3.21.so
        version: 0.3.21
threading_layer: pthreads
   architecture: Haswell

       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-41284840.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell

       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libgomp
       filepath: /home/albint/miniconda3/envs/myenv/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
```

COMMENT:
So I am just checking here, do we want to depreciate all affinity parameters in sklearn/cluster/_agglomerative.py? There are around 28 instances both in documentation and code of affinity, but only 3 mentions in the AgglomerativeClustering class. 

there are also numerous test cases mentioning affinity in some private classes as well as public there

Labels: Bug, help wanted