Talip7/scikit-learn-issues-multilabel huggingface dataset:
Allow `norm=None` in `preprocessing.Normalizer`

### Describe the workflow you want to enable

I would like to be able to set `norm=None` in `preprocessing.Normalizer`, so that I can eaily tune `norm` as part of a pipeline. Currently, `norm` can only be one of `{‘l1’, ‘l2’, ‘max’}`. 

### Describe your proposed solution

Change `Normalizer` and associated functions (eg, `normalize`) to allow `norm=None`.

This would not be a massive change in API, especially given `feature_extraction.text.TfidfVectorizer` also has a `norm` keyword argument that can be `None`.

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

The alternative would be to retain the existing behaviour and require that people use `"passthrough"` to fulfil the requirement I have described above. This is an OK solution, but being able to set `norm=None` feels more intuitive to me. In fact, I tried this at first, assuming it would work based on my experience with `feature_extraction.text.TfidfVectorizer`, and was then surprised when it didn't.

If there is a general principle that I'm not aware of that explains the decision not to allow `norm=None` then fair enough. (I am thinking, for example, that there might be a view that a `Transformer` shouldn't allow a `passthrough` through any combination of keyword arguments.)

### Additional context

If this change would be accepted then I am happy to make a PR for it.

COMMENT:
Hi, @pdhall99 The recommended way is to use the string ``"passthrough"`` in place of the pipeline step.

There's no reason to allow the Normalizer to act like a passthrough and not all other transformers, and it's not in our plan to do that for all transformers since this is what "passthrough" is for.

Labels: New Feature
Allow `norm=None` in `preprocessing.Normalizer`

### Describe the workflow you want to enable

I would like to be able to set `norm=None` in `preprocessing.Normalizer`, so that I can eaily tune `norm` as part of a pipeline. Currently, `norm` can only be one of `{‘l1’, ‘l2’, ‘max’}`. 

### Describe your proposed solution

Change `Normalizer` and associated functions (eg, `normalize`) to allow `norm=None`.

This would not be a massive change in API, especially given `feature_extraction.text.TfidfVectorizer` also has a `norm` keyword argument that can be `None`.

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

The alternative would be to retain the existing behaviour and require that people use `"passthrough"` to fulfil the requirement I have described above. This is an OK solution, but being able to set `norm=None` feels more intuitive to me. In fact, I tried this at first, assuming it would work based on my experience with `feature_extraction.text.TfidfVectorizer`, and was then surprised when it didn't.

If there is a general principle that I'm not aware of that explains the decision not to allow `norm=None` then fair enough. (I am thinking, for example, that there might be a view that a `Transformer` shouldn't allow a `passthrough` through any combination of keyword arguments.)

### Additional context

If this change would be accepted then I am happy to make a PR for it.

COMMENT:
Thanks @jeremiedbb. That makes sense.

Labels: New Feature
Figure is shown incorrectly

### Describe the issue linked to the documentation

Second part of the [figure](https://scikit-learn.org/stable/modules/gaussian_process.html#dot-product-kernel) doesn't show sampled functions

### Suggest a potential alternative/fix

_No response_

COMMENT:
This is not an issue with the figure. However, this is linked to the `ConvergenceWarning` obtain when generating this example: https://scikit-learn.org/stable/auto_examples/gaussian_process/plot_gpr_prior_posterior.html

We need to investigate if this is normal or how we could try to remove this warning to have a better figure.

Labels: Documentation, Needs Investigation
⚠️ CI failed on Wheel builder ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/4320199634)** (Mar 03, 2023)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/4329176818) on Mar 04, 2023

Labels: Needs Triage
Differences in scalar vs vectorized predictions with `GaussianProcessRegressor`

### Describe the bug

I would expect that calling `GaussianProcessRegressor.predict(X)` with a single X matrix, or with repeated scalar evaluations rows of X should would give nearly the same result, but they don't.

An example is given below.

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd
from sklearn.gaussian_process import GaussianProcessRegressor
from sklearn.gaussian_process.kernels import DotProduct, RBF
from sklearn.model_selection import train_test_split


data_url = "http://lib.stat.cmu.edu/datasets/boston"
raw_df = pd.read_csv(data_url, sep="\s+", skiprows=22, header=None)
data = np.hstack([raw_df.values[::2, :], raw_df.values[1::2, :2]])
target = raw_df.values[1::2, 2]


def evaluate_gpr_vec_and_scalar(gpr, X):
    res_vector = gpr.predict(X).squeeze()
    res_scalar = np.array([gpr.predict(xi.reshape(1, -1)) for xi in X]).squeeze()
    return res_scalar, res_vector

# load/split data
X_train, X_test, y_train, y_test = train_test_split(data, target, random_state=0)

# train
gpr = GaussianProcessRegressor(DotProduct() + RBF(), alpha=1.)
gpr.fit(X_train, y_train)

# predict scalar and vector
pred_scalar, pred_vector = evaluate_gpr_vec_and_scalar(gpr, X_test)
err = pred_scalar - pred_vector
print(err.max())
```

### Expected Results

I would expect the error to be 0 or small - perhaps around machine `eps`, if anything.

### Actual Results

`2.1609594114124775e-08`


### Versions

```shell
System:
    python: 3.10.6 | packaged by conda-forge | (main, Aug 22 2022, 20:41:54) [Clang 13.0.1 ]
executable: /Users/phil/miniconda3/envs/skl/bin/python
   machine: macOS-12.5.1-x86_64-i386-64bit
Python dependencies:
      sklearn: 1.1.1
          pip: 22.3
   setuptools: 65.5.0
        numpy: 1.23.4
        scipy: 1.9.3
       Cython: None
       pandas: 1.5.1
   matplotlib: 3.6.1
       joblib: 1.2.0
threadpoolctl: 3.1.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/phil/miniconda3/envs/skl/lib/libopenblasp-r0.3.21.dylib
        version: 0.3.21
threading_layer: openmp
   architecture: Nehalem
    num_threads: 8
       user_api: openmp
   internal_api: openmp
         prefix: libomp
       filepath: /Users/phil/miniconda3/envs/skl/lib/libomp.dylib
        version: None
    num_threads: 8
```

COMMENT:
The condition number of `K_trans` is:

```
np.linalg.cond(K_trans) = 2441679943182.803
```

so maybe probably the solution to this is not numerical stable and could cause the discrepancy:

```python
            V = solve_triangular(
                self.L_, K_trans.T, lower=GPR_CHOLESKY_LOWER, check_finite=False
            )
```

Labels: Bug, Needs Investigation, Numerical Stability
Differences in scalar vs vectorized predictions with `GaussianProcessRegressor`

### Describe the bug

I would expect that calling `GaussianProcessRegressor.predict(X)` with a single X matrix, or with repeated scalar evaluations rows of X should would give nearly the same result, but they don't.

An example is given below.

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd
from sklearn.gaussian_process import GaussianProcessRegressor
from sklearn.gaussian_process.kernels import DotProduct, RBF
from sklearn.model_selection import train_test_split


data_url = "http://lib.stat.cmu.edu/datasets/boston"
raw_df = pd.read_csv(data_url, sep="\s+", skiprows=22, header=None)
data = np.hstack([raw_df.values[::2, :], raw_df.values[1::2, :2]])
target = raw_df.values[1::2, 2]


def evaluate_gpr_vec_and_scalar(gpr, X):
    res_vector = gpr.predict(X).squeeze()
    res_scalar = np.array([gpr.predict(xi.reshape(1, -1)) for xi in X]).squeeze()
    return res_scalar, res_vector

# load/split data
X_train, X_test, y_train, y_test = train_test_split(data, target, random_state=0)

# train
gpr = GaussianProcessRegressor(DotProduct() + RBF(), alpha=1.)
gpr.fit(X_train, y_train)

# predict scalar and vector
pred_scalar, pred_vector = evaluate_gpr_vec_and_scalar(gpr, X_test)
err = pred_scalar - pred_vector
print(err.max())
```

### Expected Results

I would expect the error to be 0 or small - perhaps around machine `eps`, if anything.

### Actual Results

`2.1609594114124775e-08`


### Versions

```shell
System:
    python: 3.10.6 | packaged by conda-forge | (main, Aug 22 2022, 20:41:54) [Clang 13.0.1 ]
executable: /Users/phil/miniconda3/envs/skl/bin/python
   machine: macOS-12.5.1-x86_64-i386-64bit
Python dependencies:
      sklearn: 1.1.1
          pip: 22.3
   setuptools: 65.5.0
        numpy: 1.23.4
        scipy: 1.9.3
       Cython: None
       pandas: 1.5.1
   matplotlib: 3.6.1
       joblib: 1.2.0
threadpoolctl: 3.1.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/phil/miniconda3/envs/skl/lib/libopenblasp-r0.3.21.dylib
        version: 0.3.21
threading_layer: openmp
   architecture: Nehalem
    num_threads: 8
       user_api: openmp
   internal_api: openmp
         prefix: libomp
       filepath: /Users/phil/miniconda3/envs/skl/lib/libomp.dylib
        version: None
    num_threads: 8
```

COMMENT:
I checked that with the RBF kernel alone, we do not have the problem.

With the `DotProduct` kernel alone we get:

```
/Users/ogrisel/code/scikit-learn/sklearn/gaussian_process/_gpr.py:629: ConvergenceWarning: lbfgs failed to converge (status=2):
ABNORMAL_TERMINATION_IN_LNSRCH.

Increase the number of iterations (max_iter) or scale the data as shown in:
    https://scikit-learn.org/stable/modules/preprocessing.html
  _check_optimize_result("lbfgs", opt_res)
2.0055939131680134e-08
```

Labels: Bug, Needs Investigation, Numerical Stability
Differences in scalar vs vectorized predictions with `GaussianProcessRegressor`

### Describe the bug

I would expect that calling `GaussianProcessRegressor.predict(X)` with a single X matrix, or with repeated scalar evaluations rows of X should would give nearly the same result, but they don't.

An example is given below.

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd
from sklearn.gaussian_process import GaussianProcessRegressor
from sklearn.gaussian_process.kernels import DotProduct, RBF
from sklearn.model_selection import train_test_split


data_url = "http://lib.stat.cmu.edu/datasets/boston"
raw_df = pd.read_csv(data_url, sep="\s+", skiprows=22, header=None)
data = np.hstack([raw_df.values[::2, :], raw_df.values[1::2, :2]])
target = raw_df.values[1::2, 2]


def evaluate_gpr_vec_and_scalar(gpr, X):
    res_vector = gpr.predict(X).squeeze()
    res_scalar = np.array([gpr.predict(xi.reshape(1, -1)) for xi in X]).squeeze()
    return res_scalar, res_vector

# load/split data
X_train, X_test, y_train, y_test = train_test_split(data, target, random_state=0)

# train
gpr = GaussianProcessRegressor(DotProduct() + RBF(), alpha=1.)
gpr.fit(X_train, y_train)

# predict scalar and vector
pred_scalar, pred_vector = evaluate_gpr_vec_and_scalar(gpr, X_test)
err = pred_scalar - pred_vector
print(err.max())
```

### Expected Results

I would expect the error to be 0 or small - perhaps around machine `eps`, if anything.

### Actual Results

`2.1609594114124775e-08`


### Versions

```shell
System:
    python: 3.10.6 | packaged by conda-forge | (main, Aug 22 2022, 20:41:54) [Clang 13.0.1 ]
executable: /Users/phil/miniconda3/envs/skl/bin/python
   machine: macOS-12.5.1-x86_64-i386-64bit
Python dependencies:
      sklearn: 1.1.1
          pip: 22.3
   setuptools: 65.5.0
        numpy: 1.23.4
        scipy: 1.9.3
       Cython: None
       pandas: 1.5.1
   matplotlib: 3.6.1
       joblib: 1.2.0
threadpoolctl: 3.1.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/phil/miniconda3/envs/skl/lib/libopenblasp-r0.3.21.dylib
        version: 0.3.21
threading_layer: openmp
   architecture: Nehalem
    num_threads: 8
       user_api: openmp
   internal_api: openmp
         prefix: libomp
       filepath: /Users/phil/miniconda3/envs/skl/lib/libomp.dylib
        version: None
    num_threads: 8
```

COMMENT:
I am not sure what to do to fix this problem.

Labels: Bug, Needs Investigation, Numerical Stability
Differences in scalar vs vectorized predictions with `GaussianProcessRegressor`

### Describe the bug

I would expect that calling `GaussianProcessRegressor.predict(X)` with a single X matrix, or with repeated scalar evaluations rows of X should would give nearly the same result, but they don't.

An example is given below.

### Steps/Code to Reproduce

```python
import numpy as np
import pandas as pd
from sklearn.gaussian_process import GaussianProcessRegressor
from sklearn.gaussian_process.kernels import DotProduct, RBF
from sklearn.model_selection import train_test_split


data_url = "http://lib.stat.cmu.edu/datasets/boston"
raw_df = pd.read_csv(data_url, sep="\s+", skiprows=22, header=None)
data = np.hstack([raw_df.values[::2, :], raw_df.values[1::2, :2]])
target = raw_df.values[1::2, 2]


def evaluate_gpr_vec_and_scalar(gpr, X):
    res_vector = gpr.predict(X).squeeze()
    res_scalar = np.array([gpr.predict(xi.reshape(1, -1)) for xi in X]).squeeze()
    return res_scalar, res_vector

# load/split data
X_train, X_test, y_train, y_test = train_test_split(data, target, random_state=0)

# train
gpr = GaussianProcessRegressor(DotProduct() + RBF(), alpha=1.)
gpr.fit(X_train, y_train)

# predict scalar and vector
pred_scalar, pred_vector = evaluate_gpr_vec_and_scalar(gpr, X_test)
err = pred_scalar - pred_vector
print(err.max())
```

### Expected Results

I would expect the error to be 0 or small - perhaps around machine `eps`, if anything.

### Actual Results

`2.1609594114124775e-08`


### Versions

```shell
System:
    python: 3.10.6 | packaged by conda-forge | (main, Aug 22 2022, 20:41:54) [Clang 13.0.1 ]
executable: /Users/phil/miniconda3/envs/skl/bin/python
   machine: macOS-12.5.1-x86_64-i386-64bit
Python dependencies:
      sklearn: 1.1.1
          pip: 22.3
   setuptools: 65.5.0
        numpy: 1.23.4
        scipy: 1.9.3
       Cython: None
       pandas: 1.5.1
   matplotlib: 3.6.1
       joblib: 1.2.0
threadpoolctl: 3.1.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /Users/phil/miniconda3/envs/skl/lib/libopenblasp-r0.3.21.dylib
        version: 0.3.21
threading_layer: openmp
   architecture: Nehalem
    num_threads: 8
       user_api: openmp
   internal_api: openmp
         prefix: libomp
       filepath: /Users/phil/miniconda3/envs/skl/lib/libomp.dylib
        version: None
    num_threads: 8
```

COMMENT:
BTW @whophil I edited your code snippet to load the Boston dataset with pandas from the original URL and be able to reproduce the problem with the latest versions of scikit-learn (including the dev branch).

Labels: Bug, Needs Investigation, Numerical Stability
Verbose for Gaussian Process regression

### Describe the workflow you want to enable

I would like to monitor the progress of my fit function for a Gaussian Process. 

### Describe your proposed solution

if verbose >= 1 print the parameters "theta" and the log marginal likelihood. Maybe offer the option to return the log likelihood with a dict for the tried thetas.
- In general any verbose would be very welcome. To get a rough estimate of the progress. 

Please and thank you.

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

_No response_

### Additional context

_No response_

COMMENT:
> if verbose >= 1 print the parameters "theta" and the log marginal likelihood.

Feel free to open a PR for this. This should be pretty uncontroversial to review and merge.

> Maybe offer the option to return the log likelihood with a dict for the tried thetas.

Assuming those are not numerous values, we could probably store 2 arrays as fitted attributes on the estimator for post-fit inspection.

```python
self.explored_thetas_ = ...
self.explored_thetas_loglikelihoods_ = ...
```

Labels: New Feature
Verbose for Gaussian Process regression

### Describe the workflow you want to enable

I would like to monitor the progress of my fit function for a Gaussian Process. 

### Describe your proposed solution

if verbose >= 1 print the parameters "theta" and the log marginal likelihood. Maybe offer the option to return the log likelihood with a dict for the tried thetas.
- In general any verbose would be very welcome. To get a rough estimate of the progress. 

Please and thank you.

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

_No response_

### Additional context

_No response_

COMMENT:
Hi! Is someone working on this issue? If not, I would be glad to help.

Labels: New Feature
Verbose for Gaussian Process regression

### Describe the workflow you want to enable

I would like to monitor the progress of my fit function for a Gaussian Process. 

### Describe your proposed solution

if verbose >= 1 print the parameters "theta" and the log marginal likelihood. Maybe offer the option to return the log likelihood with a dict for the tried thetas.
- In general any verbose would be very welcome. To get a rough estimate of the progress. 

Please and thank you.

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

_No response_

### Additional context

_No response_

COMMENT:
/take

Labels: New Feature
wrong display

### Describe the bug

why is it not displaying properly?

### Steps/Code to Reproduce

from sklearn.metrics import classification_report

classification_report(y_test,y_pred, target_names=['normal','Toxicity'])

### Expected Results

No error

### Actual Results

![image](https://user-images.githubusercontent.com/92215956/221808999-21d71bb1-c6bf-4584-aeed-024ccec0d13b.png)


### Versions

```shell
System:
    python: 3.8.10 (default, Nov 14 2022, 12:59:47)  [GCC 9.4.0]
executable: /usr/bin/python3
   machine: Linux-5.10.147+-x86_64-with-glibc2.29

Python dependencies:
          pip: 22.0.4
   setuptools: 57.4.0
      sklearn: 1.0.2
        numpy: 1.22.4
        scipy: 1.7.3
       Cython: 0.29.33
       pandas: 1.3.5
   matplotlib: 3.5.3
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True
```

COMMENT:
As noted in the [classification_report doc's](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.classification_report.html#sklearn.metrics.classification_report) example section, the report needs to be printed to render the newlines:

```python

from sklearn.metrics import classification_report

print(classification_report(y_test,y_pred, target_names=['normal','Toxicity']))
```

Labels: Bug, Needs Triage
wrong display

### Describe the bug

why is it not displaying properly?

### Steps/Code to Reproduce

from sklearn.metrics import classification_report

classification_report(y_test,y_pred, target_names=['normal','Toxicity'])

### Expected Results

No error

### Actual Results

![image](https://user-images.githubusercontent.com/92215956/221808999-21d71bb1-c6bf-4584-aeed-024ccec0d13b.png)


### Versions

```shell
System:
    python: 3.8.10 (default, Nov 14 2022, 12:59:47)  [GCC 9.4.0]
executable: /usr/bin/python3
   machine: Linux-5.10.147+-x86_64-with-glibc2.29

Python dependencies:
          pip: 22.0.4
   setuptools: 57.4.0
      sklearn: 1.0.2
        numpy: 1.22.4
        scipy: 1.7.3
       Cython: 0.29.33
       pandas: 1.3.5
   matplotlib: 3.5.3
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True
```

COMMENT:
i got it. Thanks

Labels: Bug, Needs Triage
Doubled prefix operators "not" and "~" should not be used python:S2761

### Describe the bug

Only found one instance but should be worth improving since is in tutorial sections. 

Calling the not or ~ prefix operator twice might be redundant: the second invocation undoes the first. Such mistakes are typically caused by accidentally double-tapping the key in question without noticing. Either this is a bug, if the operator was actually meant to be called once, or misleading if done on purpose. Calling not twice is commonly done instead of using the dedicated "bool()" builtin function. However, the latter one increases the code readability and should be used.

### Steps/Code to Reproduce

a = 0
b = False

c = not not a # Noncompliant
d = ~~b # Noncompliant

### Expected Results

Same functional result, true/false but improve readability.

### Actual Results

Syntax and readability issue.

### Versions

```shell
OS Windows 10, Python 3.8 Pandas 1.5.0
```

COMMENT:
Since https://github.com/scikit-learn/scikit-learn/pull/25724 fixed the only found instance, I'll close this as completed. Thanks @DayneSorvisto

Labels: Bug, Needs Triage
Is the check of strict convergence in KMeans too expensive for the benefits ?

### Describe the bug

In `KMeans` scikit-learn defines [`strict_convergence`](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/cluster/_kmeans.py#L701) as the event of producing the same label assignments at two successive iterations.

When this happens, it means convergence for both labels and centroids (set aside possible oscillations due to numerical instability, were the iterations to continue).

But checking for strict convergence seems to be somewhat expensive (one loop over the last two label assignments of each sample per iteration), and if the user properly set `tol` it doesn't seem necessary at all ?

Checking for strict convergence seems to really help when `tol==0`. With `tol==0` I've seen cases of endless oscillations around 0 because of numerical instability, but never reaching 0, and finally terminating at `max_iter` iterations.

For the general case, isn't it detrimental to performance though ? one can expect the performance cost to be significant for small dimensions of data, for which an additional pass on a column is marginally more expensive.

So I would maybe suggest the following improvements:

- [ ] enable automatically the strict convergence checks only if `tol==0` (or if `tol` is "very small")
- [ ] maybe expose to the user the choice of enabling strict convergence at each iteration ?


### Versions

```shell
1.3
```

COMMENT:
> For the general case, isn't it detrimental to performance though ? one can expect the performance cost to be significant for small dimensions of data, for which an additional pass on a column is marginally more expensive.

I think a quick benchmark (or a profiling) to confirm when or if this is the case would really help making a more informed decision.

Labels: Bug, module:cluster, Needs Investigation