Talip7/scikit-learn-issues-multilabel huggingface dataset:
LassoCV fails when I pass weights.

### Describe the bug

LassoCV throws the following error when I pass weights in .fit

ValueError: Input contains NaN.

The X, y as well as the weights do not contain any NaN values.

### Steps/Code to Reproduce

```
estimator_params = {'cv': 25, 'tol': 0.0001, 'max_iter': 500, 'alphas': [0.001, 0.003, 0.005, 0.007, 0.009, 0.0001, 0.0005], 'n_jobs': -1, 'precompute': True, 'selection': 'random', 'fit_intercept': True, 'positive': False, 'random_state': 2020}
estimator = LassoCV(**estimator_params)
estimator.fit( X, y, wts)
```
[wts.txt](https://github.com/scikit-learn/scikit-learn/files/12243195/wts.txt)
[X.txt](https://github.com/scikit-learn/scikit-learn/files/12243196/X.txt)
[y.txt](https://github.com/scikit-learn/scikit-learn/files/12243197/y.txt)


### Expected Results

No error is thrown.

### Actual Results

ValueError: Input contains NaN.



### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /local_disk0/pythonVirtualEnvDirs/virtualEnv-cfd639f7-075b-4940-b5a6-959b505608aa/bin/python
   machine: Linux-5.15.0-1041-azure-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.3.0
          pip: 21.0.1
   setuptools: 52.0.0
        numpy: 1.22.4
        scipy: 1.6.2
       Cython: 0.29.23
       pandas: 1.2.4
   matplotlib: 3.4.2
       joblib: 1.3.1
threadpoolctl: 2.1.0

Built with OpenMP: True
Exception ignored on calling ctypes callback function: <function _ThreadpoolInfo._find_modules_with_dl_iterate_phdr.<locals>.match_module_callback at 0x7f6a96aa58b0>
Traceback (most recent call last):
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 400, in match_module_callback
    self._make_module_from_path(filepath)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 515, in _make_module_from_path
    module = module_class(filepath, prefix, user_api, internal_api)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 606, in __init__
    self.version = self.get_version()
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 646, in get_version
    config = get_config().split()
AttributeError: 'NoneType' object has no attribute 'split'

threadpoolctl info:
       filepath: /databricks/python3/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
         prefix: libgomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4

       filepath: /databricks/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-085ca80a.3.9.so
         prefix: libopenblas
       user_api: blas
   internal_api: openblas
        version: 0.3.9
    num_threads: 4
threading_layer: pthreads
```

COMMENT:
Sorry for that please check this out.

[X.txt](https://github.com/scikit-learn/scikit-learn/files/12251234/X.txt)

Labels: Needs Reproducible Code
LassoCV fails when I pass weights.

### Describe the bug

LassoCV throws the following error when I pass weights in .fit

ValueError: Input contains NaN.

The X, y as well as the weights do not contain any NaN values.

### Steps/Code to Reproduce

```
estimator_params = {'cv': 25, 'tol': 0.0001, 'max_iter': 500, 'alphas': [0.001, 0.003, 0.005, 0.007, 0.009, 0.0001, 0.0005], 'n_jobs': -1, 'precompute': True, 'selection': 'random', 'fit_intercept': True, 'positive': False, 'random_state': 2020}
estimator = LassoCV(**estimator_params)
estimator.fit( X, y, wts)
```
[wts.txt](https://github.com/scikit-learn/scikit-learn/files/12243195/wts.txt)
[X.txt](https://github.com/scikit-learn/scikit-learn/files/12243196/X.txt)
[y.txt](https://github.com/scikit-learn/scikit-learn/files/12243197/y.txt)


### Expected Results

No error is thrown.

### Actual Results

ValueError: Input contains NaN.



### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /local_disk0/pythonVirtualEnvDirs/virtualEnv-cfd639f7-075b-4940-b5a6-959b505608aa/bin/python
   machine: Linux-5.15.0-1041-azure-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.3.0
          pip: 21.0.1
   setuptools: 52.0.0
        numpy: 1.22.4
        scipy: 1.6.2
       Cython: 0.29.23
       pandas: 1.2.4
   matplotlib: 3.4.2
       joblib: 1.3.1
threadpoolctl: 2.1.0

Built with OpenMP: True
Exception ignored on calling ctypes callback function: <function _ThreadpoolInfo._find_modules_with_dl_iterate_phdr.<locals>.match_module_callback at 0x7f6a96aa58b0>
Traceback (most recent call last):
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 400, in match_module_callback
    self._make_module_from_path(filepath)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 515, in _make_module_from_path
    module = module_class(filepath, prefix, user_api, internal_api)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 606, in __init__
    self.version = self.get_version()
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 646, in get_version
    config = get_config().split()
AttributeError: 'NoneType' object has no attribute 'split'

threadpoolctl info:
       filepath: /databricks/python3/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
         prefix: libgomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4

       filepath: /databricks/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-085ca80a.3.9.so
         prefix: libopenblas
       user_api: blas
   internal_api: openblas
        version: 0.3.9
    num_threads: 4
threading_layer: pthreads
```

COMMENT:
Thanks for reporting the issue. Could you please also include a [minimal and reproducible example](http://sscce.org/) for us to better diagnose the problem?

Ideally we should be able to copy/paste your code to reproduce the issue, w/o having to download anything.

Labels: Needs Reproducible Code
LassoCV fails when I pass weights.

### Describe the bug

LassoCV throws the following error when I pass weights in .fit

ValueError: Input contains NaN.

The X, y as well as the weights do not contain any NaN values.

### Steps/Code to Reproduce

```
estimator_params = {'cv': 25, 'tol': 0.0001, 'max_iter': 500, 'alphas': [0.001, 0.003, 0.005, 0.007, 0.009, 0.0001, 0.0005], 'n_jobs': -1, 'precompute': True, 'selection': 'random', 'fit_intercept': True, 'positive': False, 'random_state': 2020}
estimator = LassoCV(**estimator_params)
estimator.fit( X, y, wts)
```
[wts.txt](https://github.com/scikit-learn/scikit-learn/files/12243195/wts.txt)
[X.txt](https://github.com/scikit-learn/scikit-learn/files/12243196/X.txt)
[y.txt](https://github.com/scikit-learn/scikit-learn/files/12243197/y.txt)


### Expected Results

No error is thrown.

### Actual Results

ValueError: Input contains NaN.



### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /local_disk0/pythonVirtualEnvDirs/virtualEnv-cfd639f7-075b-4940-b5a6-959b505608aa/bin/python
   machine: Linux-5.15.0-1041-azure-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.3.0
          pip: 21.0.1
   setuptools: 52.0.0
        numpy: 1.22.4
        scipy: 1.6.2
       Cython: 0.29.23
       pandas: 1.2.4
   matplotlib: 3.4.2
       joblib: 1.3.1
threadpoolctl: 2.1.0

Built with OpenMP: True
Exception ignored on calling ctypes callback function: <function _ThreadpoolInfo._find_modules_with_dl_iterate_phdr.<locals>.match_module_callback at 0x7f6a96aa58b0>
Traceback (most recent call last):
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 400, in match_module_callback
    self._make_module_from_path(filepath)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 515, in _make_module_from_path
    module = module_class(filepath, prefix, user_api, internal_api)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 606, in __init__
    self.version = self.get_version()
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 646, in get_version
    config = get_config().split()
AttributeError: 'NoneType' object has no attribute 'split'

threadpoolctl info:
       filepath: /databricks/python3/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
         prefix: libgomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4

       filepath: /databricks/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-085ca80a.3.9.so
         prefix: libopenblas
       user_api: blas
   internal_api: openblas
        version: 0.3.9
    num_threads: 4
threading_layer: pthreads
```

COMMENT:
I'm not sure, but it seems the problem is in negative sample weights

Labels: Needs Reproducible Code
LassoCV fails when I pass weights.

### Describe the bug

LassoCV throws the following error when I pass weights in .fit

ValueError: Input contains NaN.

The X, y as well as the weights do not contain any NaN values.

### Steps/Code to Reproduce

```
estimator_params = {'cv': 25, 'tol': 0.0001, 'max_iter': 500, 'alphas': [0.001, 0.003, 0.005, 0.007, 0.009, 0.0001, 0.0005], 'n_jobs': -1, 'precompute': True, 'selection': 'random', 'fit_intercept': True, 'positive': False, 'random_state': 2020}
estimator = LassoCV(**estimator_params)
estimator.fit( X, y, wts)
```
[wts.txt](https://github.com/scikit-learn/scikit-learn/files/12243195/wts.txt)
[X.txt](https://github.com/scikit-learn/scikit-learn/files/12243196/X.txt)
[y.txt](https://github.com/scikit-learn/scikit-learn/files/12243197/y.txt)


### Expected Results

No error is thrown.

### Actual Results

ValueError: Input contains NaN.



### Versions

```shell
System:
    python: 3.8.10 (default, May 26 2023, 14:05:08)  [GCC 9.4.0]
executable: /local_disk0/pythonVirtualEnvDirs/virtualEnv-cfd639f7-075b-4940-b5a6-959b505608aa/bin/python
   machine: Linux-5.15.0-1041-azure-x86_64-with-glibc2.29

Python dependencies:
      sklearn: 1.3.0
          pip: 21.0.1
   setuptools: 52.0.0
        numpy: 1.22.4
        scipy: 1.6.2
       Cython: 0.29.23
       pandas: 1.2.4
   matplotlib: 3.4.2
       joblib: 1.3.1
threadpoolctl: 2.1.0

Built with OpenMP: True
Exception ignored on calling ctypes callback function: <function _ThreadpoolInfo._find_modules_with_dl_iterate_phdr.<locals>.match_module_callback at 0x7f6a96aa58b0>
Traceback (most recent call last):
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 400, in match_module_callback
    self._make_module_from_path(filepath)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 515, in _make_module_from_path
    module = module_class(filepath, prefix, user_api, internal_api)
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 606, in __init__
    self.version = self.get_version()
  File "/databricks/python/lib/python3.8/site-packages/threadpoolctl.py", line 646, in get_version
    config = get_config().split()
AttributeError: 'NoneType' object has no attribute 'split'

threadpoolctl info:
       filepath: /databricks/python3/lib/python3.8/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
         prefix: libgomp
       user_api: openmp
   internal_api: openmp
        version: None
    num_threads: 4

       filepath: /databricks/python3/lib/python3.8/site-packages/scipy.libs/libopenblasp-r0-085ca80a.3.9.so
         prefix: libopenblas
       user_api: blas
   internal_api: openblas
        version: 0.3.9
    num_threads: 4
threading_layer: pthreads
```

COMMENT:
Closing as we haven't had a response from the OP.

Labels: Needs Reproducible Code
API Deprecate `paired_distances` and `paired_*_distances`

## Background

We have several public functions `paired_*_distances` which exist primarily as specialized implementations for the public `paired_distances` function. This function is thus either a wrapper around the specialized `paired_*_distances` or a simple iteration over the input data. During the drafting meeting, we discussed the deprecation of these functions. This discussion continued on a recent PR ([start here](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1655985340)). I wanted to open this to see if we could come to a quick consensus on our intent for the `paired_*` functions.

Personally, I definitely want to see `paired_*_distances` deprecated. I have no idea how widely used `paired_distances` is in practice. I believe @thomasjpfan has a better sense of this after some github searches. If it is not too widely used, I am also in favor of deprecating it as a whole.

As @adrinjalali mentioned ([cf. comment](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1660010966)) the `paired_distances` function is a really light function that most users ought to be able to write themselves. It doesn't really make sense for us to provide it for them...

cc: @scikit-learn/core-devs 

**Edit: Consensus is to deprecate both `paired_*_distances` and `paired_distances`**

COMMENT:
I am +1 regarding deprecating and removing `paired_*_distances`.

I think we need to know if `paired_distances` is significantly used before taking any decision (I do not know any alternative to the global search of GitHub).

Labels: Moderate, API, help wanted, module:metrics
API Deprecate `paired_distances` and `paired_*_distances`

## Background

We have several public functions `paired_*_distances` which exist primarily as specialized implementations for the public `paired_distances` function. This function is thus either a wrapper around the specialized `paired_*_distances` or a simple iteration over the input data. During the drafting meeting, we discussed the deprecation of these functions. This discussion continued on a recent PR ([start here](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1655985340)). I wanted to open this to see if we could come to a quick consensus on our intent for the `paired_*` functions.

Personally, I definitely want to see `paired_*_distances` deprecated. I have no idea how widely used `paired_distances` is in practice. I believe @thomasjpfan has a better sense of this after some github searches. If it is not too widely used, I am also in favor of deprecating it as a whole.

As @adrinjalali mentioned ([cf. comment](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1660010966)) the `paired_distances` function is a really light function that most users ought to be able to write themselves. It doesn't really make sense for us to provide it for them...

cc: @scikit-learn/core-devs 

**Edit: Consensus is to deprecate both `paired_*_distances` and `paired_distances`**

COMMENT:
I'm in favor of deprecating them all, if too many users complain, we can reverse action, but the implementation is trivial, so we shouldn't have any issues removing them.

Labels: Moderate, API, help wanted, module:metrics
API Deprecate `paired_distances` and `paired_*_distances`

## Background

We have several public functions `paired_*_distances` which exist primarily as specialized implementations for the public `paired_distances` function. This function is thus either a wrapper around the specialized `paired_*_distances` or a simple iteration over the input data. During the drafting meeting, we discussed the deprecation of these functions. This discussion continued on a recent PR ([start here](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1655985340)). I wanted to open this to see if we could come to a quick consensus on our intent for the `paired_*` functions.

Personally, I definitely want to see `paired_*_distances` deprecated. I have no idea how widely used `paired_distances` is in practice. I believe @thomasjpfan has a better sense of this after some github searches. If it is not too widely used, I am also in favor of deprecating it as a whole.

As @adrinjalali mentioned ([cf. comment](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1660010966)) the `paired_distances` function is a really light function that most users ought to be able to write themselves. It doesn't really make sense for us to provide it for them...

cc: @scikit-learn/core-devs 

**Edit: Consensus is to deprecate both `paired_*_distances` and `paired_distances`**

COMMENT:
@StefanieSenger this is a medium-scope task, in case you would be interested in taking it on. If not I can mark it as `help wanted` 😄

Labels: Moderate, API, help wanted, module:metrics
API Deprecate `paired_distances` and `paired_*_distances`

## Background

We have several public functions `paired_*_distances` which exist primarily as specialized implementations for the public `paired_distances` function. This function is thus either a wrapper around the specialized `paired_*_distances` or a simple iteration over the input data. During the drafting meeting, we discussed the deprecation of these functions. This discussion continued on a recent PR ([start here](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1655985340)). I wanted to open this to see if we could come to a quick consensus on our intent for the `paired_*` functions.

Personally, I definitely want to see `paired_*_distances` deprecated. I have no idea how widely used `paired_distances` is in practice. I believe @thomasjpfan has a better sense of this after some github searches. If it is not too widely used, I am also in favor of deprecating it as a whole.

As @adrinjalali mentioned ([cf. comment](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1660010966)) the `paired_distances` function is a really light function that most users ought to be able to write themselves. It doesn't really make sense for us to provide it for them...

cc: @scikit-learn/core-devs 

**Edit: Consensus is to deprecate both `paired_*_distances` and `paired_distances`**

COMMENT:
Would like to open PR

Labels: Moderate, API, help wanted, module:metrics
API Deprecate `paired_distances` and `paired_*_distances`

## Background

We have several public functions `paired_*_distances` which exist primarily as specialized implementations for the public `paired_distances` function. This function is thus either a wrapper around the specialized `paired_*_distances` or a simple iteration over the input data. During the drafting meeting, we discussed the deprecation of these functions. This discussion continued on a recent PR ([start here](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1655985340)). I wanted to open this to see if we could come to a quick consensus on our intent for the `paired_*` functions.

Personally, I definitely want to see `paired_*_distances` deprecated. I have no idea how widely used `paired_distances` is in practice. I believe @thomasjpfan has a better sense of this after some github searches. If it is not too widely used, I am also in favor of deprecating it as a whole.

As @adrinjalali mentioned ([cf. comment](https://github.com/scikit-learn/scikit-learn/pull/22705#issuecomment-1660010966)) the `paired_distances` function is a really light function that most users ought to be able to write themselves. It doesn't really make sense for us to provide it for them...

cc: @scikit-learn/core-devs 

**Edit: Consensus is to deprecate both `paired_*_distances` and `paired_distances`**

COMMENT:
Seen the ping only now. If there is something I can support you with, @Shreesha3112, please let me know. :)

Labels: Moderate, API, help wanted, module:metrics
Wrong behaviour when calculating `f1_score` with `zero_division=1`

### Describe the bug

It seems that in the new version 1.3 `f1_score` with `zero_division=1` incorrectly calculates the results. It treats the prediction with 0 true positives as a division by zero and assigned 1. This was not the case in 1.2.X version and below, which were triggering division by zero only when true positives, false negatives, and false positives were 0. The example below demonstrates the issue. This bug may result in over-positive estimates, especially when using `macro` averaging in multi-label classification.

### Steps/Code to Reproduce

```
y_true = np.array([0, 1])
y_pred = np.array([1, 0])
print(f1_score(y_true, y_pred, zero_division=1)) # Should be 0.0

y_true = np.array([0, 1])
y_pred = np.array([0, 1])
print(f1_score(y_true, y_pred, zero_division=1)) # Should be 1.0

y_true = np.array([0, 1])
y_pred = np.array([0, 0])
print(f1_score(y_true, y_pred, zero_division=1)) # Should be 0.0

y_true = np.array([0, 0])
y_pred = np.array([0, 0])
print(f1_score(y_true, y_pred, zero_division=1)) # Here division by zero should be triggered resulting in 1.0
```

### Expected Results

In versions 1.2.X and below, the correct results are printed, that is `0.0, 1.0, 0.0, 1.0`,

### Actual Results

The new version 1.3 prints `1.0, 1.0, 0.0, 1.0` - the first value is incorrect.

### Versions

```shell
System:
    python: 3.10.6 (main, May 29 2023, 11:10:38) [GCC 11.3.0]
executable: /usr/bin/python
   machine: Linux-5.19.0-50-generic-x86_64-with-glibc2.35

Python dependencies:
      sklearn: 1.3.0
          pip: 22.0.2
   setuptools: 59.6.0
        numpy: 1.25.1
        scipy: 1.10.0
       Cython: None
       pandas: 1.5.3
   matplotlib: 3.7.1
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /home/marek/.local/lib/python3.10/site-packages/scikit_learn.libs/libgomp-a34b3233.so.1.0.0
        version: None
    num_threads: 16

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /usr/local/lib/python3.10/dist-packages/numpy.libs/libopenblas64_p-r0-7a851222.3.23.so
        version: 0.3.23
threading_layer: pthreads
   architecture: Zen
    num_threads: 16

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/marek/.local/lib/python3.10/site-packages/scipy.libs/libopenblasp-r0-41284840.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: Zen
    num_threads: 16
```

COMMENT:
Indeed, it seems that we have some bad handling here. We need to solve the issue.

Labels: Bug, help wanted