Talip7/scikit-learn-issues-multilabel huggingface dataset:
Issues with pairwise_distances(metric='euclidean') when used on the output of UMAP

### Describe the bug

When using pairwise_distances with metric='euclidean' on the output of some data from a UMAP, a `RuntimeWarning: divide by zero encountered in matmul ret = a @ b` is raised. This warning is not raised if you just use pairwise_distances on some normally distributed values of the same dimension, it specifically happens when used on the output of UMAP. The warning is not raised if calling `scipy.pdist` on the same data. The warning doesn't come up with any other metric (other than euclidean family e.g. nan_euclidean etc)

### Steps/Code to Reproduce

```python
import numpy as np
import umap.umap_ as umap 
from sklearn.metrics import pairwise_distances

np.random.seed(42)
arr = np.random.normal(size = (300, 10))
reducer = umap.UMAP()
embedding = reducer.fit_transform(arr)

# this line produces the warning 
dist_mat = pairwise_distances(embedding, metric = 'euclidean')

# no warning produced by this code
synthetic = np.random.normal(size = (300, 2))
dist_mat_synth = pairwise_distances(synthetic, metric = 'euclidean')
```

### Expected Results

Would expect to see no RuntimeWarning (FutureWarning is expected)

### Actual Results

``` 

[.../site-packages/sklearn/utils/deprecation.py:151]: FutureWarning: 'force_all_finite' was renamed to 'ensure_all_finite' in 1.6 and will be removed in 1.8.
  warnings.warn(
[.../site-packages/sklearn/utils/extmath.py:203] RuntimeWarning: divide by zero encountered in matmul
  ret = a @ b
[.../site-packages/sklearn/utils/extmath.py:203]: RuntimeWarning: overflow encountered in matmul
  ret = a @ b
[.../site-packages/sklearn/utils/extmath.py:203]: RuntimeWarning: invalid value encountered in matmul
  ret = a @ b

```

### Versions

```shell
System:
    python: 3.10.16 (main, Feb 25 2025, 09:29:51) [Clang 16.0.0 (clang-1600.0.26.6)]
executable: .../bin/python
   machine: macOS-15.4-arm64-arm-64bit

Python dependencies:
      sklearn: 1.6.1
          pip: 25.0.1
   setuptools: 65.5.0
        numpy: 2.1.3
        scipy: 1.15.1
       Cython: None
       pandas: 2.2.3
   matplotlib: 3.10.0
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 14
         prefix: libomp
       filepath: .../site-packages/sklearn/.dylibs/libomp.dylib
        version: None

       user_api: openmp
   internal_api: openmp
    num_threads: 14
         prefix: libomp
       filepath: /opt/homebrew/Cellar/libomp/19.1.7/lib/libomp.dylib
        version: None
```

COMMENT:
I’m unable to reproduce this issue on my ARM-based Mac (Apple Silicon), running Python 3.10.16 and the following library versions:

- libomp 20.1.3 (installed via Homebrew, keg-only)
- scikit-learn 1.7.dev0 (editable install from source)
- numpy 2.1.3
- scipy 1.15.1
- joblib 1.4.2
- threadpoolctl 3.5.0
- Cython 3.0.12
- matplotlib 3.10.0
- pandas 2.2.3
- setuptools 65.5.0

I’ve tested with pairwise_distances(metric="euclidean") on UMAP outputs and am not seeing any RuntimeWarning or overflow issues. Everything runs as expected.

Labels: Bug, Needs Investigation
Issues with pairwise_distances(metric='euclidean') when used on the output of UMAP

### Describe the bug

When using pairwise_distances with metric='euclidean' on the output of some data from a UMAP, a `RuntimeWarning: divide by zero encountered in matmul ret = a @ b` is raised. This warning is not raised if you just use pairwise_distances on some normally distributed values of the same dimension, it specifically happens when used on the output of UMAP. The warning is not raised if calling `scipy.pdist` on the same data. The warning doesn't come up with any other metric (other than euclidean family e.g. nan_euclidean etc)

### Steps/Code to Reproduce

```python
import numpy as np
import umap.umap_ as umap 
from sklearn.metrics import pairwise_distances

np.random.seed(42)
arr = np.random.normal(size = (300, 10))
reducer = umap.UMAP()
embedding = reducer.fit_transform(arr)

# this line produces the warning 
dist_mat = pairwise_distances(embedding, metric = 'euclidean')

# no warning produced by this code
synthetic = np.random.normal(size = (300, 2))
dist_mat_synth = pairwise_distances(synthetic, metric = 'euclidean')
```

### Expected Results

Would expect to see no RuntimeWarning (FutureWarning is expected)

### Actual Results

``` 

[.../site-packages/sklearn/utils/deprecation.py:151]: FutureWarning: 'force_all_finite' was renamed to 'ensure_all_finite' in 1.6 and will be removed in 1.8.
  warnings.warn(
[.../site-packages/sklearn/utils/extmath.py:203] RuntimeWarning: divide by zero encountered in matmul
  ret = a @ b
[.../site-packages/sklearn/utils/extmath.py:203]: RuntimeWarning: overflow encountered in matmul
  ret = a @ b
[.../site-packages/sklearn/utils/extmath.py:203]: RuntimeWarning: invalid value encountered in matmul
  ret = a @ b

```

### Versions

```shell
System:
    python: 3.10.16 (main, Feb 25 2025, 09:29:51) [Clang 16.0.0 (clang-1600.0.26.6)]
executable: .../bin/python
   machine: macOS-15.4-arm64-arm-64bit

Python dependencies:
      sklearn: 1.6.1
          pip: 25.0.1
   setuptools: 65.5.0
        numpy: 2.1.3
        scipy: 1.15.1
       Cython: None
       pandas: 2.2.3
   matplotlib: 3.10.0
       joblib: 1.4.2
threadpoolctl: 3.5.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 14
         prefix: libomp
       filepath: .../site-packages/sklearn/.dylibs/libomp.dylib
        version: None

       user_api: openmp
   internal_api: openmp
    num_threads: 14
         prefix: libomp
       filepath: /opt/homebrew/Cellar/libomp/19.1.7/lib/libomp.dylib
        version: None
```

COMMENT:
@griffinfarrow since we cannot reproduce on our machines, could you please run your script in a way that output raises an exception with a full traceback, e.g. by inserting the following in your script?

```python
import warnings
warnings.filterwarnings('error', category=RuntimeWarning)
```

and update the description of the issue with to include the traceback?

Labels: Bug, Needs Investigation
DOC Examples (imputation): add scaling when using k-neighbours imputation

### Describe the issue linked to the documentation

Two examples for missing-values imputation use k-neighbors imputation without scaling data first.
As a result, the approaches under-perform.
The examples are:

1. https://scikit-learn.org/stable/auto_examples/impute/plot_missing_values.html#sphx-glr-auto-examples-impute-plot-missing-values-py
2. https://scikit-learn.org/stable/auto_examples/impute/plot_iterative_imputer_variants_comparison.html

In the first example, the effect is quite small, adding scaling before calling k-neighbours imputer changes MSE for the california dataset for k-NN from 0.2987 ± 0.1469 to 0.2912 ± 0.1410 and for the diabetes dataset from 3314 ± 114  to 3323 ± 90.

In the second example (comparing iterative imputations), the change is more significant: before the change, iterative imputation with k-neighbors performed worse than imputation with mean, after the scaling -- it performs better than mean imputation.

In both cases, it is a better practice to scale data before using a k-neighbors approach which is based on distances between points.

![Image](https://github.com/user-attachments/assets/167560c9-3011-425f-a29f-74548fc9e8bc)

### Suggest a potential alternative/fix

I will submit a patch to fix an issue.

COMMENT:
I agree that k-NN requires feature scaling in general.

Labels: Documentation
scikit-learn not included in conda env creation step for bleeding-edge install

### Describe the issue linked to the documentation

On the [Contributing](https://scikit-learn.org/stable/developers/contributing.html) page, under "How to contribute", Step 4 guides users to the "Building from source" section, which links to:

 [Advanced Installation – Install bleeding-edge](https://scikit-learn.org/stable/developers/advanced_installation.html#install-bleeding-edge)

However, in Step 2 of that page (the conda environment creation command), the scikit-learn package itself is not mentioned or included.

![Image](https://github.com/user-attachments/assets/d9ec66cb-7d2b-4708-8ce6-27dd6317f55f)
but Step 6 asks to Check that the installed scikit-learn has a version number ending with .dev0 which raises errors if scikit-learn is not installed in the virtual environment

![Image](https://github.com/user-attachments/assets/4c04dec8-e112-441c-a941-e0d3bc1d0861)


### Suggest a potential alternative/fix

_No response_

COMMENT:
Hi @sanjyay, have you done all the steps ? scikit-learn is compiled and installed at step 5.

Labels: Documentation
scikit-learn not included in conda env creation step for bleeding-edge install

### Describe the issue linked to the documentation

On the [Contributing](https://scikit-learn.org/stable/developers/contributing.html) page, under "How to contribute", Step 4 guides users to the "Building from source" section, which links to:

 [Advanced Installation – Install bleeding-edge](https://scikit-learn.org/stable/developers/advanced_installation.html#install-bleeding-edge)

However, in Step 2 of that page (the conda environment creation command), the scikit-learn package itself is not mentioned or included.

![Image](https://github.com/user-attachments/assets/d9ec66cb-7d2b-4708-8ce6-27dd6317f55f)
but Step 6 asks to Check that the installed scikit-learn has a version number ending with .dev0 which raises errors if scikit-learn is not installed in the virtual environment

![Image](https://github.com/user-attachments/assets/4c04dec8-e112-441c-a941-e0d3bc1d0861)


### Suggest a potential alternative/fix

_No response_

COMMENT:
@jeremiedbb I was not able to compile from source since I was using python=3.13 and thought that Step 4 is part of Step 3 that is alternate approach to conda. Upon viewing issue #31149 , I downgraded my python version to 3.12 and now I am able to build from source. Thank you.

Labels: Documentation
Upper bound the build dependencies in `pyproject.toml` for release branches

### Describe the workflow you want to enable

Upper bound the build dependencies on release branches makes it easier to build the wheel in the future. This has two benefits:

- The wheels become easier to build when using the newest build dependency does not work. (Historically, I've seen issues with Cython)
- If we wanted to backport a fix the wheel building is more stable.

### Describe your proposed solution

On release branches, provide a upper bound to the build dependencies in `pyproject.toml`.

SciPy does this already: https://github.com/scipy/scipy/blob/e3228cdfe42e403ed203db16e4db4822eb416797/pyproject.toml#L1-L13

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

Leave the build dependencies to be unbounded.

COMMENT:
Hi, I'd like to work on this. 

Just to clarify the scope:
- This change would only apply to the pyproject.toml files on release branches (e.g. 1.6.X, 1.5.X, etc.), correct?
- Should the upper bounds be based on the latest known working versions at the time of the release, or is there a preferred policy for setting them?
- Are there specific build dependencies you'd like to target (e.g. Cython, setuptools, wheel, etc.), or should I mirror the approach used in SciPy?

I took a look at the SciPy example you shared and it makes sense. Happy to draft a PR once I confirm the above.

Labels: Build / CI, Needs Decision
Upper bound the build dependencies in `pyproject.toml` for release branches

### Describe the workflow you want to enable

Upper bound the build dependencies on release branches makes it easier to build the wheel in the future. This has two benefits:

- The wheels become easier to build when using the newest build dependency does not work. (Historically, I've seen issues with Cython)
- If we wanted to backport a fix the wheel building is more stable.

### Describe your proposed solution

On release branches, provide a upper bound to the build dependencies in `pyproject.toml`.

SciPy does this already: https://github.com/scipy/scipy/blob/e3228cdfe42e403ed203db16e4db4822eb416797/pyproject.toml#L1-L13

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

Leave the build dependencies to be unbounded.

COMMENT:
@RishabhSpark I do not recommend working on this yet. The maintainers need to decide if this is a good idea before we move forward with an implementation.

---

> This change would only apply to the pyproject.toml files on release branches (e.g. 1.6.X, 1.5.X, etc.), correct?

Yes

> Should the upper bounds be based on the latest known working versions at the time of the release, or is there a preferred policy for setting them?

If we have a upper bound, then we need a policy. I'll say the current version that works at the time.

> Are there specific build dependencies you'd like to target (e.g. Cython, setuptools, wheel, etc.), or should I mirror the approach used in SciPy?

Only for the build dependencies listed here: https://github.com/scikit-learn/scikit-learn/blob/cd119bb24293bb8bfcbef97d8b53c992c75286b2/pyproject.toml#L99-L104

Labels: Build / CI, Needs Decision
Upper bound the build dependencies in `pyproject.toml` for release branches

### Describe the workflow you want to enable

Upper bound the build dependencies on release branches makes it easier to build the wheel in the future. This has two benefits:

- The wheels become easier to build when using the newest build dependency does not work. (Historically, I've seen issues with Cython)
- If we wanted to backport a fix the wheel building is more stable.

### Describe your proposed solution

On release branches, provide a upper bound to the build dependencies in `pyproject.toml`.

SciPy does this already: https://github.com/scipy/scipy/blob/e3228cdfe42e403ed203db16e4db4822eb416797/pyproject.toml#L1-L13

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

Leave the build dependencies to be unbounded.

COMMENT:
> [@RishabhSpark](https://github.com/RishabhSpark) I do not recommend working on this yet. The maintainers need to decide if this is a good idea before we move forward with an implementation.
> 
> > This change would only apply to the pyproject.toml files on release branches (e.g. 1.6.X, 1.5.X, etc.), correct?
> 
> Yes
> 
> > Should the upper bounds be based on the latest known working versions at the time of the release, or is there a preferred policy for setting them?
> 
> If we have a upper bound, then we need a policy. I'll saw the current version that works at the time.
> 
> > Are there specific build dependencies you'd like to target (e.g. Cython, setuptools, wheel, etc.), or should I mirror the approach used in SciPy?
> 
> Only for the build dependencies listed here:
> 
> [scikit-learn/pyproject.toml](https://github.com/scikit-learn/scikit-learn/blob/cd119bb24293bb8bfcbef97d8b53c992c75286b2/pyproject.toml#L99-L104)
> 
> Lines 99 to 104 in [cd119bb](/scikit-learn/scikit-learn/commit/cd119bb24293bb8bfcbef97d8b53c992c75286b2)
> 
>  requires = [ 
>      "meson-python>=0.16.0", 
>      "Cython>=3.0.10", 
>      "numpy>=2", 
>      "scipy>=1.8.0", 
>  ]

Thanks for the letting me know! That makes sense — I'll wait for the inputs from maintainers on the policy or next steps before proceeding.

Labels: Build / CI, Needs Decision
Upper bound the build dependencies in `pyproject.toml` for release branches

### Describe the workflow you want to enable

Upper bound the build dependencies on release branches makes it easier to build the wheel in the future. This has two benefits:

- The wheels become easier to build when using the newest build dependency does not work. (Historically, I've seen issues with Cython)
- If we wanted to backport a fix the wheel building is more stable.

### Describe your proposed solution

On release branches, provide a upper bound to the build dependencies in `pyproject.toml`.

SciPy does this already: https://github.com/scipy/scipy/blob/e3228cdfe42e403ed203db16e4db4822eb416797/pyproject.toml#L1-L13

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

Leave the build dependencies to be unbounded.

COMMENT:
In terms of picking a version as the upper bound: why not use `cython=x.y.z` with the version that was current when the branch was created? Basically, why use an upper bound if we could use `=`? Feels like I missed something

I think in general this doesn't sound like a terrible idea. At least I can't immediately think of a reason not to do this

Labels: Build / CI, Needs Decision
Upper bound the build dependencies in `pyproject.toml` for release branches

### Describe the workflow you want to enable

Upper bound the build dependencies on release branches makes it easier to build the wheel in the future. This has two benefits:

- The wheels become easier to build when using the newest build dependency does not work. (Historically, I've seen issues with Cython)
- If we wanted to backport a fix the wheel building is more stable.

### Describe your proposed solution

On release branches, provide a upper bound to the build dependencies in `pyproject.toml`.

SciPy does this already: https://github.com/scipy/scipy/blob/e3228cdfe42e403ed203db16e4db4822eb416797/pyproject.toml#L1-L13

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

Leave the build dependencies to be unbounded.

COMMENT:
> In terms of picking a version as the upper bound: why not use cython=x.y.z with the version that was current when the branch was created? Basically, why use an upper bound if we could use =? Feels like I missed something

I think it's mostly to pick up bug fixes and a little more lenient for packages managers building from source.

In any case, I'm mostly okay with having a hard `cython==x.y.z` dependency for building.

Labels: Build / CI, Needs Decision
Upper bound the build dependencies in `pyproject.toml` for release branches

### Describe the workflow you want to enable

Upper bound the build dependencies on release branches makes it easier to build the wheel in the future. This has two benefits:

- The wheels become easier to build when using the newest build dependency does not work. (Historically, I've seen issues with Cython)
- If we wanted to backport a fix the wheel building is more stable.

### Describe your proposed solution

On release branches, provide a upper bound to the build dependencies in `pyproject.toml`.

SciPy does this already: https://github.com/scipy/scipy/blob/e3228cdfe42e403ed203db16e4db4822eb416797/pyproject.toml#L1-L13

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

Leave the build dependencies to be unbounded.

COMMENT:
I am fine with this. We can start implementing this policy in the future 1.7.X release branch.

But we probably need to start updating the maintainers guide in `doc/developers/maintainer.rst.template`.

/cc @jeremiedbb

Labels: Build / CI, Needs Decision
Upper bound the build dependencies in `pyproject.toml` for release branches

### Describe the workflow you want to enable

Upper bound the build dependencies on release branches makes it easier to build the wheel in the future. This has two benefits:

- The wheels become easier to build when using the newest build dependency does not work. (Historically, I've seen issues with Cython)
- If we wanted to backport a fix the wheel building is more stable.

### Describe your proposed solution

On release branches, provide a upper bound to the build dependencies in `pyproject.toml`.

SciPy does this already: https://github.com/scipy/scipy/blob/e3228cdfe42e403ed203db16e4db4822eb416797/pyproject.toml#L1-L13

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

Leave the build dependencies to be unbounded.

COMMENT:
This could also be helpful for #28151.

Labels: Build / CI, Needs Decision
⚠️ CI failed on Wheel builder (last failure: Apr 11, 2025) ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/14395159536)** (Apr 11, 2025)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/14415886529) on Apr 12, 2025

Labels: Needs Triage
How is the progress of sklearn1.7?[help wanted]

### Describe the workflow you want to enable

Excuse me, is sklearn1.7.dev0 available now? How to install it?  

### Describe your proposed solution

none

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

_No response_

### Additional context

_No response_

COMMENT:
Hi @kongjunZhang, I invite you to follow the instructions to install the development version of scikit-learn here https://scikit-learn.org/stable/developers/advanced_installation.html#installing-the-development-version-of-scikit-learn.

For the future please note that this is more a usage question that should be asked on stack overflow or on the discussions tab (https://github.com/scikit-learn/scikit-learn/discussions). The issue tracker should be about bug reports and feature requests.

Labels: New Feature, Needs Triage
Fix ConvergenceWarning in `plot_gpr_on_structured_data.py` example

This issue is about addressing a `ConvergenceWarning` that occurs when running the `examples/gaussian_process/plot_gpr_on_structured_data.py `example in CI (also when building the documentation locally).

The example creates three plots. The last use case on a classification of DNA sequences throws a `ConvergenceWarning` related to the `baseline_similarity_bounds` defined in a custom kernel when fitting. It seems that the lower bound is pushed resulting in the lack of convergence.

This occurs with the setting `baseline_similarity_bounds=(1e-5, 1))` in the custom kernel.

Even setting `baseline_similarity_bounds=(1e-40, 1)) ` results in the same warning:
```
ConvergenceWarning: The optimal value found for dimension 0 of parameter baseline_similarity is close to the specified lower bound 1e-40. Decreasing the bound and calling fit again may find a better value.
```

Lowering the bound further with `baseline_similarity_bounds=(1e-50, 1)) ` results in a different warning stemming from `lbfgs`:
```
ConvergenceWarning: lbfgs failed to converge (status=2): ABNORMAL: .
Increase the number of iterations (max_iter) or scale the data as shown in: https://scikit-learn.org/stable/modules/preprocessing.html
```

It would be preferable to resolve this so the example can be build without displaying warnings.


While being at the example, other small improvements are welcome (for instance fixing the typo in "use of kernel functions that operates" (the s in operates)).

COMMENT:
Hi! I'd like to try to work on this issue.

Labels: help wanted, Needs Investigation