Talip7/scikit-learn-issues-multilabel huggingface dataset:
`set_output` API no longer changing the name of the output columns

### Describe the bug

In scikit-learn versions prior to 1.3.0 I was able to change the name of the output data using the set_output API, in version 1.3.0 the output data names are no longer changed. Is this a bug? Or was I using this functionality incorrectly?

### Steps/Code to Reproduce

``` python
from sklearn.base import OneToOneFeatureMixin, TransformerMixin, BaseEstimator
import pandas as pd

df = pd.DataFrame({"a": [-1, -100, 10, 0, 4]})

class PlusN(OneToOneFeatureMixin, TransformerMixin, BaseEstimator):
    def __init__(self, n: int=1) -> None:
        super().__init__()
        self.n = 10
    def transform(self, X):
        return X + self.n
    def fit(self, X):
        self.feature_names_in_ = X.columns
        return self
    def get_feature_names_out(self, input_features = None):
        feat = super().get_feature_names_out(input_features)
        return [f + "_NEW_NAME" for f in feat]
    
PlusN().set_output(transform="pandas").fit_transform(df)
```

### Expected Results

In scikit-learn versions less than 1.3.0 I see this on the output. With the output data renamed, as I would expect.
![image](https://github.com/scikit-learn/scikit-learn/assets/38221700/6d1065f9-5719-480a-8992-5d49b694e398)



### Actual Results

Now in scikit-learn 1.3.0 the column is not renamed.
![image](https://github.com/scikit-learn/scikit-learn/assets/38221700/53ce02c3-3213-4274-ac35-0c4d54c5ffeb)


### Versions

```shell
System:
    python: 3.10.4 | packaged by conda-forge | (main, Mar 30 2022, 08:38:02) [MSC v.1916 64 bit (AMD64)]
executable: c:\<some path>\python.exe
   machine: Windows-10-10.0.22621-SP0

Python dependencies:
      sklearn: 1.3.0
          pip: 23.1.2
   setuptools: 58.1.0
        numpy: 1.23.4
        scipy: 1.9.2
       Cython: None
       pandas: 1.5.3
   matplotlib: 3.6.0
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: vcomp
       filepath: C:\<>\.env\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: C:\<>\.env\Lib\site-packages\numpy\.libs\libopenblas.FB5AE2TYXYH2IJRDKGDGQ3XBKLKTF43H.gfortran-win_amd64.dll
        version: 0.3.20
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: C:\<>\.env\Lib\site-packages\scipy.libs\libopenblas-57db09cfe174768fb409a6bb5a530d4c.dll
        version: 0.3.18
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 8
```

COMMENT:
Actually we already have the info here: https://scikit-learn.org/dev/developers/develop.html#universal-attributes

However, we could revisit the documentation to see if we can better blend all of those concepts/requirements.

Labels: Documentation
`set_output` API no longer changing the name of the output columns

### Describe the bug

In scikit-learn versions prior to 1.3.0 I was able to change the name of the output data using the set_output API, in version 1.3.0 the output data names are no longer changed. Is this a bug? Or was I using this functionality incorrectly?

### Steps/Code to Reproduce

``` python
from sklearn.base import OneToOneFeatureMixin, TransformerMixin, BaseEstimator
import pandas as pd

df = pd.DataFrame({"a": [-1, -100, 10, 0, 4]})

class PlusN(OneToOneFeatureMixin, TransformerMixin, BaseEstimator):
    def __init__(self, n: int=1) -> None:
        super().__init__()
        self.n = 10
    def transform(self, X):
        return X + self.n
    def fit(self, X):
        self.feature_names_in_ = X.columns
        return self
    def get_feature_names_out(self, input_features = None):
        feat = super().get_feature_names_out(input_features)
        return [f + "_NEW_NAME" for f in feat]
    
PlusN().set_output(transform="pandas").fit_transform(df)
```

### Expected Results

In scikit-learn versions less than 1.3.0 I see this on the output. With the output data renamed, as I would expect.
![image](https://github.com/scikit-learn/scikit-learn/assets/38221700/6d1065f9-5719-480a-8992-5d49b694e398)



### Actual Results

Now in scikit-learn 1.3.0 the column is not renamed.
![image](https://github.com/scikit-learn/scikit-learn/assets/38221700/53ce02c3-3213-4274-ac35-0c4d54c5ffeb)


### Versions

```shell
System:
    python: 3.10.4 | packaged by conda-forge | (main, Mar 30 2022, 08:38:02) [MSC v.1916 64 bit (AMD64)]
executable: c:\<some path>\python.exe
   machine: Windows-10-10.0.22621-SP0

Python dependencies:
      sklearn: 1.3.0
          pip: 23.1.2
   setuptools: 58.1.0
        numpy: 1.23.4
        scipy: 1.9.2
       Cython: None
       pandas: 1.5.3
   matplotlib: 3.6.0
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: vcomp
       filepath: C:\<>\.env\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: C:\<>\.env\Lib\site-packages\numpy\.libs\libopenblas.FB5AE2TYXYH2IJRDKGDGQ3XBKLKTF43H.gfortran-win_amd64.dll
        version: 0.3.20
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: C:\<>\.env\Lib\site-packages\scipy.libs\libopenblas-57db09cfe174768fb409a6bb5a530d4c.dll
        version: 0.3.18
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 8
```

COMMENT:
Ah, OK, thanks, yeah it was unclear to me we needed to define both those parameters for the set output API to work as expected.

Labels: Documentation
In `HDBSCAN`, `algorithm="kdtree"` is not consistent with other estimator

Other estimators (k-NN, DBSCAN, etc.) use `algorihtm="kd_tree"`. In `HDBSCAN`, the name is called `"kdtree"` which is not consistent. This could be part of the next bug-fix release.

COMMENT:
I would like to open PR for this

Labels: help wanted
In `HDBSCAN`, `algorithm="kdtree"` is not consistent with other estimator

Other estimators (k-NN, DBSCAN, etc.) use `algorihtm="kd_tree"`. In `HDBSCAN`, the name is called `"kdtree"` which is not consistent. This could be part of the next bug-fix release.

COMMENT:
This fix is also applicable to `ball_tree `algorithm

In HDBSCAN : `algorithm : {"auto", "brute", "kdtree", "balltree"}`
In DBSCAN:  `algorithm : {'auto', 'ball_tree', 'kd_tree', 'brute'}`

Labels: help wanted
In `HDBSCAN`, `algorithm="kdtree"` is not consistent with other estimator

Other estimators (k-NN, DBSCAN, etc.) use `algorihtm="kd_tree"`. In `HDBSCAN`, the name is called `"kdtree"` which is not consistent. This could be part of the next bug-fix release.

COMMENT:
Indeed this is the same issue for BallTree as well. Looking forward for the reviewing the fix @Shreesha3112

Labels: help wanted
dbscan uses large amount of ram

### Describe the bug

I'm using sklearn version 1.1.2 . In the following code dbscan uses about 15GB of memory. The size of `xy` is 2.88MB. This can't be right. 

```python
from sklearn.cluster import dbscan
import numpy as np
nclust = 12
cluster_size = 15000
xy = []
for i in range(nclust):
    centre = np.random.uniform(0, 20000, (1,2))
    cluster = np.random.randn(cluster_size, 2) * 15 + centre
    xy.append(cluster)
xy = np.vstack(xy)
dbscan(xy, eps=40, min_samples=10, algorithm='kd_tree', leaf_size=500)
```

### Steps/Code to Reproduce

```python
from sklearn.cluster import dbscan
import numpy as np
nclust = 12
cluster_size = 15000
xy = []
for i in range(nclust):
    centre = np.random.uniform(0, 20000, (1,2))
    cluster = np.random.randn(cluster_size, 2) * 15 + centre
    xy.append(cluster)
xy = np.vstack(xy)
dbscan(xy, eps=40, min_samples=10, algorithm='kd_tree', leaf_size=500)
```

### Expected Results

No sure

### Actual Results

15GB of RAM usage by dbscan execution

### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /home/vcn81216/fileserver_home/python/python3/bin/python
   machine: Linux-5.15.0-75-generic-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.1.2
          pip: 23.1.2
   setuptools: 59.1.0
        numpy: 1.23.2
        scipy: 1.9.1
       Cython: 0.29.23
       pandas: 1.4.4
   matplotlib: 3.5.3
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 12

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/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: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-9f9f5dbc.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 12
```

COMMENT:
The memory usage can grow to `n_samples ** 2`, especially when `eps` is large.

However this is not mentioned in the docstring:

- https://scikit-learn.org/stable/modules/generated/sklearn.cluster.DBSCAN.html

We can probably improve the docstring for `eps`, e.g. maybe cross link to the user guide subsection on memory consumption: https://scikit-learn.org/stable/modules/clustering.html#dbscan

I am no sure what HDBSCAN do on this kind of data. Maybe you can give it a try?

Labels: Bug, Documentation
dbscan uses large amount of ram

### Describe the bug

I'm using sklearn version 1.1.2 . In the following code dbscan uses about 15GB of memory. The size of `xy` is 2.88MB. This can't be right. 

```python
from sklearn.cluster import dbscan
import numpy as np
nclust = 12
cluster_size = 15000
xy = []
for i in range(nclust):
    centre = np.random.uniform(0, 20000, (1,2))
    cluster = np.random.randn(cluster_size, 2) * 15 + centre
    xy.append(cluster)
xy = np.vstack(xy)
dbscan(xy, eps=40, min_samples=10, algorithm='kd_tree', leaf_size=500)
```

### Steps/Code to Reproduce

```python
from sklearn.cluster import dbscan
import numpy as np
nclust = 12
cluster_size = 15000
xy = []
for i in range(nclust):
    centre = np.random.uniform(0, 20000, (1,2))
    cluster = np.random.randn(cluster_size, 2) * 15 + centre
    xy.append(cluster)
xy = np.vstack(xy)
dbscan(xy, eps=40, min_samples=10, algorithm='kd_tree', leaf_size=500)
```

### Expected Results

No sure

### Actual Results

15GB of RAM usage by dbscan execution

### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /home/vcn81216/fileserver_home/python/python3/bin/python
   machine: Linux-5.15.0-75-generic-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.1.2
          pip: 23.1.2
   setuptools: 59.1.0
        numpy: 1.23.2
        scipy: 1.9.1
       Cython: 0.29.23
       pandas: 1.4.4
   matplotlib: 3.5.3
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 12

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/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: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-9f9f5dbc.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 12
```

COMMENT:
This is the same issue as reported in https://github.com/scikit-learn/scikit-learn/issues/22531.

Labels: Bug, Documentation
dbscan uses large amount of ram

### Describe the bug

I'm using sklearn version 1.1.2 . In the following code dbscan uses about 15GB of memory. The size of `xy` is 2.88MB. This can't be right. 

```python
from sklearn.cluster import dbscan
import numpy as np
nclust = 12
cluster_size = 15000
xy = []
for i in range(nclust):
    centre = np.random.uniform(0, 20000, (1,2))
    cluster = np.random.randn(cluster_size, 2) * 15 + centre
    xy.append(cluster)
xy = np.vstack(xy)
dbscan(xy, eps=40, min_samples=10, algorithm='kd_tree', leaf_size=500)
```

### Steps/Code to Reproduce

```python
from sklearn.cluster import dbscan
import numpy as np
nclust = 12
cluster_size = 15000
xy = []
for i in range(nclust):
    centre = np.random.uniform(0, 20000, (1,2))
    cluster = np.random.randn(cluster_size, 2) * 15 + centre
    xy.append(cluster)
xy = np.vstack(xy)
dbscan(xy, eps=40, min_samples=10, algorithm='kd_tree', leaf_size=500)
```

### Expected Results

No sure

### Actual Results

15GB of RAM usage by dbscan execution

### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /home/vcn81216/fileserver_home/python/python3/bin/python
   machine: Linux-5.15.0-75-generic-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.1.2
          pip: 23.1.2
   setuptools: 59.1.0
        numpy: 1.23.2
        scipy: 1.9.1
       Cython: 0.29.23
       pandas: 1.4.4
   matplotlib: 3.5.3
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 12

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/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: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-9f9f5dbc.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 12
```

COMMENT:
/take

Labels: Bug, Documentation
dbscan uses large amount of ram

### Describe the bug

I'm using sklearn version 1.1.2 . In the following code dbscan uses about 15GB of memory. The size of `xy` is 2.88MB. This can't be right. 

```python
from sklearn.cluster import dbscan
import numpy as np
nclust = 12
cluster_size = 15000
xy = []
for i in range(nclust):
    centre = np.random.uniform(0, 20000, (1,2))
    cluster = np.random.randn(cluster_size, 2) * 15 + centre
    xy.append(cluster)
xy = np.vstack(xy)
dbscan(xy, eps=40, min_samples=10, algorithm='kd_tree', leaf_size=500)
```

### Steps/Code to Reproduce

```python
from sklearn.cluster import dbscan
import numpy as np
nclust = 12
cluster_size = 15000
xy = []
for i in range(nclust):
    centre = np.random.uniform(0, 20000, (1,2))
    cluster = np.random.randn(cluster_size, 2) * 15 + centre
    xy.append(cluster)
xy = np.vstack(xy)
dbscan(xy, eps=40, min_samples=10, algorithm='kd_tree', leaf_size=500)
```

### Expected Results

No sure

### Actual Results

15GB of RAM usage by dbscan execution

### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /home/vcn81216/fileserver_home/python/python3/bin/python
   machine: Linux-5.15.0-75-generic-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.1.2
          pip: 23.1.2
   setuptools: 59.1.0
        numpy: 1.23.2
        scipy: 1.9.1
       Cython: 0.29.23
       pandas: 1.4.4
   matplotlib: 3.5.3
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/site-packages/numpy.libs/libopenblas64_p-r0-742d56dc.3.20.so
        version: 0.3.20
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 12

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/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: /mnt/rclsfserv005/users/vcn81216/python/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-9f9f5dbc.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 12
```

COMMENT:
DBSCAN does not require a "batch" materialization of the neighbors.
It is a sklearn limitation that it may need this much memory.

Labels: Bug, Documentation
Array API support with lazy evaluation

At the moment, our Array API integration can implicitly assume eager evaluation semantics.

Furthermore we did not test our code to see how it would behave with candidate Array API implementations with lazy evaluation semantics (e.g. dask, jax, ...).

The purpose of this issue is to track what would be needed to make our Array API estimator work with lazy evaluation.

I think we should first investigate where this breaks, then decide whether or not we would like to support lazy evaluation semantics in scikit-learn via the Array API support and if so open a meta-issue to add common test with an estimator tag and progressively fix the Array API estimators to deal with lazy evaluation.

Note that are particular point about lazy vs eager evaluation for Array API consuming libraries is being discussed here:

- https://github.com/data-apis/array-api/issues/642

COMMENT:
I ran a quick experiment with `dask` against the PCA branch:

- https://github.com/ogrisel/scikit-learn/tree/dask-hack-pca

As you can see in the last commit (https://github.com/scikit-learn/scikit-learn/commit/a8ab0d311b5585c0c6d06b3840bf03103e9ff972), I did some hackish monkey-patches to make it work.

In the end I could successfully call scikit-learn's `PCA(n_components=2, power_iteration_normalizer="QR").fit_transform` on a dask array and get a dask array as a result and inspect the `components_` and `explained_variance_ratio_` attributes to check that are also a dask arrays (as exepcted). However calling the `.score` method causes a freeze (I did not investigate).

Note that there is a meta-issue in dask to track Array API compliance:

- for dask in particular: https://github.com/dask/dask/issues/8917
- more generally: https://github.com/data-apis/array-api/issues/402

I reported some the problems I say during my experiment and linked them to that meta-issue.

Labels: RFC, Array API
Array API support with lazy evaluation

At the moment, our Array API integration can implicitly assume eager evaluation semantics.

Furthermore we did not test our code to see how it would behave with candidate Array API implementations with lazy evaluation semantics (e.g. dask, jax, ...).

The purpose of this issue is to track what would be needed to make our Array API estimator work with lazy evaluation.

I think we should first investigate where this breaks, then decide whether or not we would like to support lazy evaluation semantics in scikit-learn via the Array API support and if so open a meta-issue to add common test with an estimator tag and progressively fix the Array API estimators to deal with lazy evaluation.

Note that are particular point about lazy vs eager evaluation for Array API consuming libraries is being discussed here:

- https://github.com/data-apis/array-api/issues/642

COMMENT:
I don't know what the status of https://github.com/dask/dask/pull/8750 is, but we can look at adding dask to the compat library if that helps things move faster. On the other hand, it may be unnecessary to do that if they are going to add array_api as a separate namespace because there won't be any backwards compatibility concerns.

Labels: RFC, Array API
Array API support with lazy evaluation

At the moment, our Array API integration can implicitly assume eager evaluation semantics.

Furthermore we did not test our code to see how it would behave with candidate Array API implementations with lazy evaluation semantics (e.g. dask, jax, ...).

The purpose of this issue is to track what would be needed to make our Array API estimator work with lazy evaluation.

I think we should first investigate where this breaks, then decide whether or not we would like to support lazy evaluation semantics in scikit-learn via the Array API support and if so open a meta-issue to add common test with an estimator tag and progressively fix the Array API estimators to deal with lazy evaluation.

Note that are particular point about lazy vs eager evaluation for Array API consuming libraries is being discussed here:

- https://github.com/data-apis/array-api/issues/642

COMMENT:
Any opinion on the above @tomwhite / @jrbourbeau? Having a temporary support for dask in [array-api-compat](https://github.com/data-apis/array-api-compat) while the official `dask.array.array_api` namespace gets finalized would probably be helpful moving things forward.

But maybe exposing two competing ways to consume dask arrays from array api agnostic code might also introduce unnecessary complexity in the long run.

Labels: RFC, Array API
Array API support with lazy evaluation

At the moment, our Array API integration can implicitly assume eager evaluation semantics.

Furthermore we did not test our code to see how it would behave with candidate Array API implementations with lazy evaluation semantics (e.g. dask, jax, ...).

The purpose of this issue is to track what would be needed to make our Array API estimator work with lazy evaluation.

I think we should first investigate where this breaks, then decide whether or not we would like to support lazy evaluation semantics in scikit-learn via the Array API support and if so open a meta-issue to add common test with an estimator tag and progressively fix the Array API estimators to deal with lazy evaluation.

Note that are particular point about lazy vs eager evaluation for Array API consuming libraries is being discussed here:

- https://github.com/data-apis/array-api/issues/642

COMMENT:
I would favour the array-api-compat route, given that NumPy is going to incorporate the Array API standard into its standard namespace (see https://github.com/dask/dask/pull/8750#issuecomment-1193166277, and the NumPy 2 work). This would mean that https://github.com/dask/dask/pull/8750 is not needed at all, avoiding another namespace to support.

The issue for adding Dask support is https://github.com/data-apis/array-api-compat/issues/17, and it should be fairly straightforward to use some of the work in https://github.com/dask/dask/pull/8750 as a guide at least.

Labels: RFC, Array API