Talip7/scikit-learn-issues-multilabel huggingface dataset:
Make an instance of ColumnTransformer pass the common test

### Describe the bug

Not sure if `check_estimator` is appropriate to use with transformers, but `ColumnTransformer` inherits from `BaseEstimator`, so I'm assuming so.

I have a custom transformer that inherits from `ColumnTransformer`, and I'm trying to use `check_estimator` to make sure I am doing so properly. However, `ColumnTransformer` itself fails on multiple tests; I'm assuming many are because creating a non-trivial `ColumnTransformer` involves specifying required feature names, which seems to go against some of the tests in `check_estimator`.

Is there a different best practice to test a custom subclass of `ColumnTransformer` and/or transformers in general?

### Steps/Code to Reproduce

```python
from sklearn.utils.estimator_checks import parametrize_with_checks
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import Normalizer

ct = ColumnTransformer(
    [
        ("norm1", Normalizer(norm="l1"), [0, 1]),
        ("norm2", Normalizer(norm="l1"), slice(2, 4)),
    ],
    remainder="passthrough",
)


@parametrize_with_checks([ct])
def test_sklearn_checks(estimator, check):
    check(estimator)
```

### Expected Results

All tests pass.

### Actual Results

[Test Results —.pdf](https://github.com/scikit-learn/scikit-learn/files/13285011/Test.Results.pdf)


### Versions

```shell
System:
    python: 3.11.6 | packaged by conda-forge | (main, Oct  3 2023, 10:37:07) [Clang 15.0.7 ]
executable: /my_env/bin/python
   machine: macOS-13.4-arm64-arm-64bit
Python dependencies:
      sklearn: 1.3.1
          pip: 23.3.1
   setuptools: 68.2.2
        numpy: 1.26.0
        scipy: 1.11.3
       Cython: None
       pandas: 2.1.1
   matplotlib: 3.8.0
       joblib: 1.3.2
threadpoolctl: 3.2.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /my_env/lib/libopenblas.0.dylib
        version: 0.3.24
threading_layer: openmp
   architecture: VORTEX
       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libomp
       filepath: /my_env/lib/libomp.dylib
        version: None
```

COMMENT:
I am not surprised that the test are not passing because we tend to generate random data with some specific shapes that would not make sense for the column definition of the `ColumnTransformer` that you have declared.

We would need to carefully review the type of data that we generate to make the common test pass for the `ColumnTransformer`. I am not sure that this would actually be the best strategy.

Labels: Enhancement
Make an instance of ColumnTransformer pass the common test

### Describe the bug

Not sure if `check_estimator` is appropriate to use with transformers, but `ColumnTransformer` inherits from `BaseEstimator`, so I'm assuming so.

I have a custom transformer that inherits from `ColumnTransformer`, and I'm trying to use `check_estimator` to make sure I am doing so properly. However, `ColumnTransformer` itself fails on multiple tests; I'm assuming many are because creating a non-trivial `ColumnTransformer` involves specifying required feature names, which seems to go against some of the tests in `check_estimator`.

Is there a different best practice to test a custom subclass of `ColumnTransformer` and/or transformers in general?

### Steps/Code to Reproduce

```python
from sklearn.utils.estimator_checks import parametrize_with_checks
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import Normalizer

ct = ColumnTransformer(
    [
        ("norm1", Normalizer(norm="l1"), [0, 1]),
        ("norm2", Normalizer(norm="l1"), slice(2, 4)),
    ],
    remainder="passthrough",
)


@parametrize_with_checks([ct])
def test_sklearn_checks(estimator, check):
    check(estimator)
```

### Expected Results

All tests pass.

### Actual Results

[Test Results —.pdf](https://github.com/scikit-learn/scikit-learn/files/13285011/Test.Results.pdf)


### Versions

```shell
System:
    python: 3.11.6 | packaged by conda-forge | (main, Oct  3 2023, 10:37:07) [Clang 15.0.7 ]
executable: /my_env/bin/python
   machine: macOS-13.4-arm64-arm-64bit
Python dependencies:
      sklearn: 1.3.1
          pip: 23.3.1
   setuptools: 68.2.2
        numpy: 1.26.0
        scipy: 1.11.3
       Cython: None
       pandas: 2.1.1
   matplotlib: 3.8.0
       joblib: 1.3.2
threadpoolctl: 3.2.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
    num_threads: 8
         prefix: libopenblas
       filepath: /my_env/lib/libopenblas.0.dylib
        version: 0.3.24
threading_layer: openmp
   architecture: VORTEX
       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libomp
       filepath: /my_env/lib/libomp.dylib
        version: None
```

COMMENT:
Traceback attached.
[traceback.txt](https://github.com/scikit-learn/scikit-learn/files/13368970/traceback.txt)

Labels: Enhancement
Clarify docstring on HistGradientBoostingRegressor regarding monotonic_cst

Hi scikit team! Enormous fan of all you do 🙏 

I'm thinking about opening a small PR and would love your thoughts.

The docs/docstring on `HistGradientBoostingRegressor` [have the following note](https://github.com/scikit-learn/scikit-learn/blob/bed14db756d39829c71dbb537f7f5041b5e792c2/sklearn/ensemble/_hist_gradient_boosting/gradient_boosting.py#L1310) about the argument `monotonic_cst`: "The constraints are only valid for binary classifications and hold over the probability of the positive class." 

Should we consider clarifying or removing this note in the `Regressor` docstring? 

The note of course makes sense in the `Classifier` docstring. Here in the `Regressor` docstring, I found this sentence a bit unclear. It technically could be read as suggesting the constraint is not valid when used with this Regressor. I suspect that is not the intended meaning, since Scikit has published a guide on [using monotonic_cst with a HistGradientBoostingRegressor](https://scikit-learn.org/stable/auto_examples/ensemble/plot_monotonic_constraints.html).

Thanks for considering! Here's the full section in question of the docstring:

>         monotonic_cst : array-like of int of shape (n_features) or dict, default=None
>
>         Monotonic constraint to enforce on each feature are specified using the
>         following integer values:
> 
>         - 1: monotonic increase
>         - 0: no constraint
>         - -1: monotonic decrease
> 
>         If a dict with str keys, map feature to monotonic constraints by name.
>         If an array, the features are mapped to constraints by position. See
>         :ref:`monotonic_cst_features_names` for a usage example.
> 
>         The constraints are only valid for binary classifications and hold
>         over the probability of the positive class.
>         Read more in the :ref:`User Guide <monotonic_cst_gbdt>`.
>

COMMENT:
Removing or at least editing it (in case there is a corresponding version for regression?) sounds like a good idea.

Labels: Needs Triage
Clarify docstring on HistGradientBoostingRegressor regarding monotonic_cst

Hi scikit team! Enormous fan of all you do 🙏 

I'm thinking about opening a small PR and would love your thoughts.

The docs/docstring on `HistGradientBoostingRegressor` [have the following note](https://github.com/scikit-learn/scikit-learn/blob/bed14db756d39829c71dbb537f7f5041b5e792c2/sklearn/ensemble/_hist_gradient_boosting/gradient_boosting.py#L1310) about the argument `monotonic_cst`: "The constraints are only valid for binary classifications and hold over the probability of the positive class." 

Should we consider clarifying or removing this note in the `Regressor` docstring? 

The note of course makes sense in the `Classifier` docstring. Here in the `Regressor` docstring, I found this sentence a bit unclear. It technically could be read as suggesting the constraint is not valid when used with this Regressor. I suspect that is not the intended meaning, since Scikit has published a guide on [using monotonic_cst with a HistGradientBoostingRegressor](https://scikit-learn.org/stable/auto_examples/ensemble/plot_monotonic_constraints.html).

Thanks for considering! Here's the full section in question of the docstring:

>         monotonic_cst : array-like of int of shape (n_features) or dict, default=None
>
>         Monotonic constraint to enforce on each feature are specified using the
>         following integer values:
> 
>         - 1: monotonic increase
>         - 0: no constraint
>         - -1: monotonic decrease
> 
>         If a dict with str keys, map feature to monotonic constraints by name.
>         If an array, the features are mapped to constraints by position. See
>         :ref:`monotonic_cst_features_names` for a usage example.
> 
>         The constraints are only valid for binary classifications and hold
>         over the probability of the positive class.
>         Read more in the :ref:`User Guide <monotonic_cst_gbdt>`.
>

COMMENT:
Awesome thank you @betatim ! Can I clarify the consideration about a corresponding version for Regression? It looks like this sentence (about binary classification) exists in the docstrings for both HistGBM classes, Classifier and Regressor. Perhaps my PR can remove the sentence from the Regressor docstring, leaving it untouched in the Classifier docstring? 

Unless there is some reason I’m unaware of that the two classes must have 1:1 identical descriptions of a shared argument?

Labels: Needs Triage
Clarify docstring on HistGradientBoostingRegressor regarding monotonic_cst

Hi scikit team! Enormous fan of all you do 🙏 

I'm thinking about opening a small PR and would love your thoughts.

The docs/docstring on `HistGradientBoostingRegressor` [have the following note](https://github.com/scikit-learn/scikit-learn/blob/bed14db756d39829c71dbb537f7f5041b5e792c2/sklearn/ensemble/_hist_gradient_boosting/gradient_boosting.py#L1310) about the argument `monotonic_cst`: "The constraints are only valid for binary classifications and hold over the probability of the positive class." 

Should we consider clarifying or removing this note in the `Regressor` docstring? 

The note of course makes sense in the `Classifier` docstring. Here in the `Regressor` docstring, I found this sentence a bit unclear. It technically could be read as suggesting the constraint is not valid when used with this Regressor. I suspect that is not the intended meaning, since Scikit has published a guide on [using monotonic_cst with a HistGradientBoostingRegressor](https://scikit-learn.org/stable/auto_examples/ensemble/plot_monotonic_constraints.html).

Thanks for considering! Here's the full section in question of the docstring:

>         monotonic_cst : array-like of int of shape (n_features) or dict, default=None
>
>         Monotonic constraint to enforce on each feature are specified using the
>         following integer values:
> 
>         - 1: monotonic increase
>         - 0: no constraint
>         - -1: monotonic decrease
> 
>         If a dict with str keys, map feature to monotonic constraints by name.
>         If an array, the features are mapped to constraints by position. See
>         :ref:`monotonic_cst_features_names` for a usage example.
> 
>         The constraints are only valid for binary classifications and hold
>         over the probability of the positive class.
>         Read more in the :ref:`User Guide <monotonic_cst_gbdt>`.
>

COMMENT:
That sounds sensible. The classes don't need to have identical doc strings. What I was wondering is if there is a corresponding sentence for regressors, if yes it would make sense to include it. However I don't know enough to know if there even is a variation on this sentence for regression (it seems like no?)

Labels: Needs Triage
Clarify docstring on HistGradientBoostingRegressor regarding monotonic_cst

Hi scikit team! Enormous fan of all you do 🙏 

I'm thinking about opening a small PR and would love your thoughts.

The docs/docstring on `HistGradientBoostingRegressor` [have the following note](https://github.com/scikit-learn/scikit-learn/blob/bed14db756d39829c71dbb537f7f5041b5e792c2/sklearn/ensemble/_hist_gradient_boosting/gradient_boosting.py#L1310) about the argument `monotonic_cst`: "The constraints are only valid for binary classifications and hold over the probability of the positive class." 

Should we consider clarifying or removing this note in the `Regressor` docstring? 

The note of course makes sense in the `Classifier` docstring. Here in the `Regressor` docstring, I found this sentence a bit unclear. It technically could be read as suggesting the constraint is not valid when used with this Regressor. I suspect that is not the intended meaning, since Scikit has published a guide on [using monotonic_cst with a HistGradientBoostingRegressor](https://scikit-learn.org/stable/auto_examples/ensemble/plot_monotonic_constraints.html).

Thanks for considering! Here's the full section in question of the docstring:

>         monotonic_cst : array-like of int of shape (n_features) or dict, default=None
>
>         Monotonic constraint to enforce on each feature are specified using the
>         following integer values:
> 
>         - 1: monotonic increase
>         - 0: no constraint
>         - -1: monotonic decrease
> 
>         If a dict with str keys, map feature to monotonic constraints by name.
>         If an array, the features are mapped to constraints by position. See
>         :ref:`monotonic_cst_features_names` for a usage example.
> 
>         The constraints are only valid for binary classifications and hold
>         over the probability of the positive class.
>         Read more in the :ref:`User Guide <monotonic_cst_gbdt>`.
>

COMMENT:
I would just remove that sentence for the HGBTRegressor: `The constraints are only valid for binary classifications and hold
    over the probability of the positive class.`

Labels: Needs Triage
Clarify docstring on HistGradientBoostingRegressor regarding monotonic_cst

Hi scikit team! Enormous fan of all you do 🙏 

I'm thinking about opening a small PR and would love your thoughts.

The docs/docstring on `HistGradientBoostingRegressor` [have the following note](https://github.com/scikit-learn/scikit-learn/blob/bed14db756d39829c71dbb537f7f5041b5e792c2/sklearn/ensemble/_hist_gradient_boosting/gradient_boosting.py#L1310) about the argument `monotonic_cst`: "The constraints are only valid for binary classifications and hold over the probability of the positive class." 

Should we consider clarifying or removing this note in the `Regressor` docstring? 

The note of course makes sense in the `Classifier` docstring. Here in the `Regressor` docstring, I found this sentence a bit unclear. It technically could be read as suggesting the constraint is not valid when used with this Regressor. I suspect that is not the intended meaning, since Scikit has published a guide on [using monotonic_cst with a HistGradientBoostingRegressor](https://scikit-learn.org/stable/auto_examples/ensemble/plot_monotonic_constraints.html).

Thanks for considering! Here's the full section in question of the docstring:

>         monotonic_cst : array-like of int of shape (n_features) or dict, default=None
>
>         Monotonic constraint to enforce on each feature are specified using the
>         following integer values:
> 
>         - 1: monotonic increase
>         - 0: no constraint
>         - -1: monotonic decrease
> 
>         If a dict with str keys, map feature to monotonic constraints by name.
>         If an array, the features are mapped to constraints by position. See
>         :ref:`monotonic_cst_features_names` for a usage example.
> 
>         The constraints are only valid for binary classifications and hold
>         over the probability of the positive class.
>         Read more in the :ref:`User Guide <monotonic_cst_gbdt>`.
>

COMMENT:
@betatim That makes sense! I haven't yet seen the regression variety of the sentence elsewhere in the scikit docs, but for sure it could exist

@lorentzenchr That's cool by me if nobody knows a replacement sentence like @betatim wondered about

Labels: Needs Triage
Wrong NDCG\DCG calculation

### Describe the bug

I try to calculate NDCG of a binary recommendations.
I assume the two lists are ordered by relevance.
So, `y_true=[1,1,1,1]` means that all the recommendations are valid.
and `y_pred=[1,1,1,0]` means that all the top-3 recommendations are valid, but the last one isn't.

I expect to get a number other than 1, but I get 1.

### Steps/Code to Reproduce

```python
from sklearn.metrics import ndcg_score
import numpy as np


y_true = np.array([[1,1,1,1]])
y_pred = np.array([[1,1,1,0]])
ndcg_score(y_true, y_pred, k=4) # returns 1.0
```

### Expected Results

```
0.8318724637288826
```

### Actual Results

The output of the current ndcg_score is 1. 

### Versions

```shell
I'm using scikit-learn version=1.3.2.
```

COMMENT:
DCG and NDCG are not for binary classification but for ranking.
If all the candidates we are trying to rank have the same relevance (1.0), any ranking we choose is as good as any other.

DCG sorts the true gains (y_true) in the order induced by y_score, then applies the discount (multiplies by decreasing weights to reflect the fact that relevant documents lower in the ranking bring less value), then computes the sum.
If all candidates (eg documents) have the same gain (relevance), 1.0 in this case, the ordering does not matter (because the gain at every index is 1.0 whatever order we choose).
Thus the ordering induced by `y_score` and the best possible ordering (induced by `y_true`) yield the same DCG, and their ratio (the NDCG) is 1.0

Labels: Bug, Needs Triage
Wrong NDCG\DCG calculation

### Describe the bug

I try to calculate NDCG of a binary recommendations.
I assume the two lists are ordered by relevance.
So, `y_true=[1,1,1,1]` means that all the recommendations are valid.
and `y_pred=[1,1,1,0]` means that all the top-3 recommendations are valid, but the last one isn't.

I expect to get a number other than 1, but I get 1.

### Steps/Code to Reproduce

```python
from sklearn.metrics import ndcg_score
import numpy as np


y_true = np.array([[1,1,1,1]])
y_pred = np.array([[1,1,1,0]])
ndcg_score(y_true, y_pred, k=4) # returns 1.0
```

### Expected Results

```
0.8318724637288826
```

### Actual Results

The output of the current ndcg_score is 1. 

### Versions

```shell
I'm using scikit-learn version=1.3.2.
```

COMMENT:
Thanks @jeromedockes for the details. I therefore close the issue.

Labels: Bug, Needs Triage
Iris Dataset Wrong Values.

### Describe the bug

There are three incorrect values in the Iris dataset, as follows:

(Instances from: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/datasets/data/iris.csv)

In Row 36, the 4th feature is recorded as 0.2 instead of 0.1.
In Row 39, the 2nd feature is noted as 3.6 instead of 3.1.
In Row 39, the 3rd feature is documented as 1.4 instead of 1.5.

From Original Iris Dataset the rows are 35

### Steps/Code to Reproduce

iris = datasets.load_iris()
X = iris.data
y = iris.target

### Expected Results

Row 36 (35 from Original Dataset):   4.9,     3.1,     1.5,      0.1,     Iris-setosa
Row 39 (38 from Original Dataset):   4.9,     3.1,     1.5,      0.1,     Iris-setosa


### Actual Results

Row 36 (35 from Original Dataset):   4.9,     3.1,     1.5,      0.2,     Iris-setosa
Row 39 (38 from Original Dataset):   4.9,     3.6,     1.4,      0.1,     Iris-setosa

### Versions

```shell
System:
    python: 3.10.9 | packaged by Anaconda, Inc. | (main, Mar  1 2023, 18:18:15) [MSC v.1916 64 bit (AMD64)]
executable: C:\Users\stylelev\AppData\Local\anaconda3\python.exe
   machine: Windows-10-10.0.22621-SP0

Python dependencies:
      sklearn: 1.2.1
          pip: 22.3.1
   setuptools: 65.6.3
        numpy: 1.23.5
        scipy: 1.10.0
       Cython: None
       pandas: 1.5.3
   matplotlib: 3.7.0
       joblib: 1.1.1
threadpoolctl: 2.2.0

Built with OpenMP: True

threadpoolctl info:
       filepath: C:\Users\stylelev\AppData\Local\anaconda3\Library\bin\mkl_rt.1.dll
         prefix: mkl_rt
       user_api: blas
   internal_api: mkl
        version: 2021.4-Product
    num_threads: 4
threading_layer: intel

       filepath: C:\Users\stylelev\AppData\Local\anaconda3\vcomp140.dll
         prefix: vcomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4
```

COMMENT:
From Original Iris Dataset the rows are 35 and 38.

Labels: Bug, Needs Triage
Iris Dataset Wrong Values.

### Describe the bug

There are three incorrect values in the Iris dataset, as follows:

(Instances from: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/datasets/data/iris.csv)

In Row 36, the 4th feature is recorded as 0.2 instead of 0.1.
In Row 39, the 2nd feature is noted as 3.6 instead of 3.1.
In Row 39, the 3rd feature is documented as 1.4 instead of 1.5.

From Original Iris Dataset the rows are 35

### Steps/Code to Reproduce

iris = datasets.load_iris()
X = iris.data
y = iris.target

### Expected Results

Row 36 (35 from Original Dataset):   4.9,     3.1,     1.5,      0.1,     Iris-setosa
Row 39 (38 from Original Dataset):   4.9,     3.1,     1.5,      0.1,     Iris-setosa


### Actual Results

Row 36 (35 from Original Dataset):   4.9,     3.1,     1.5,      0.2,     Iris-setosa
Row 39 (38 from Original Dataset):   4.9,     3.6,     1.4,      0.1,     Iris-setosa

### Versions

```shell
System:
    python: 3.10.9 | packaged by Anaconda, Inc. | (main, Mar  1 2023, 18:18:15) [MSC v.1916 64 bit (AMD64)]
executable: C:\Users\stylelev\AppData\Local\anaconda3\python.exe
   machine: Windows-10-10.0.22621-SP0

Python dependencies:
      sklearn: 1.2.1
          pip: 22.3.1
   setuptools: 65.6.3
        numpy: 1.23.5
        scipy: 1.10.0
       Cython: None
       pandas: 1.5.3
   matplotlib: 3.7.0
       joblib: 1.1.1
threadpoolctl: 2.2.0

Built with OpenMP: True

threadpoolctl info:
       filepath: C:\Users\stylelev\AppData\Local\anaconda3\Library\bin\mkl_rt.1.dll
         prefix: mkl_rt
       user_api: blas
   internal_api: mkl
        version: 2021.4-Product
    num_threads: 4
threading_layer: intel

       filepath: C:\Users\stylelev\AppData\Local\anaconda3\vcomp140.dll
         prefix: vcomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4
```

COMMENT:
What is the "Original Iris Dataset" source. Looking at https://github.com/scikit-learn/scikit-learn/pull/11082, I can see that we are using the R package and not the UCI version that is what is written in the original paper.

Labels: Bug, Needs Triage