Talip7/scikit-learn-issues-multilabel huggingface dataset:
making mutual_info_regression more verbose

### Describe the workflow you want to enable

Hi, 

Thanks for coding up `mutual_info_regression`, I use it for novel space science research and it's super helpful for me.

I'm currently using it to analyse quite large amounts of data, and understandably this can be quite slow. I'm wondering if it would be possible to implement an optional flag in `mutual_info_regression` to make the code verbose while it's running. For example, printing out something to the terminal when it is 10%, 20%, 30% (etc) done.

Just an idea - hopefully I have raised this in the correct way!

Thanks,
Alexandra Fogg

### Describe your proposed solution

Implementation of an optional flag in `mutual_info_regression` to make the function verbose, where it prints out statements at certain stages of the process, e.g. 10% done or saying that a certain stage is completed, etc.

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

_No response_

### Additional context

_No response_

COMMENT:
We show probably first get the callback: https://github.com/scikit-learn/scikit-learn/pull/22000

Then, we could use the progress bar callback.

Labels: New Feature
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
/cc @jeremiedbb @lesteve

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
I open https://github.com/pyodide/pyodide/pull/3976 to update the version of scikit-learn (or at least it is what I am aiming to)

I assume that we can update the version of pyodide once there is a new release with this new scikit-learn version.

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
Is it possible to build our own pyodide "distribution" (not sure what to call it, I'm referring to "the stuff that the pyodide project creates when they make a release")? That way we could build those artefacts as part of the docs with the latest version of scikit-learn.

It would also mean you can test drive changes that are on `main` by visiting the unstable docs. But I think that is more of a bonus feature.

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
This has been discussed before. I think the most reasonable way forward is described in https://github.com/scikit-learn/scikit-learn/pull/25887#issuecomment-1514714120.

- build a scikit-learn development wheel and upload it somewhere where it can be used by Pyodide (i.e. need some kind of CORS proxy)
- add `%pip install <full-url-behind-cors-proxy>` to the JupyterLite notebooks (through the sphinx-gallery `notebook_modification_function`)
- it means that the dev scikit-learn version will be used, but this has always been like this for Binder and nobody ever complained (or noticed)

One problem with having the wheel as part of the doc is that you add a ~6MB wheel on each push to the doc repo.

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
Alternatively we could hide the jupyterlite links on `/stable` between the time of release X.Y.Z and the time scikit-learn X.Y.Z is shipped with pyodide and push a commit to the maintenance branch to update `/stable` as soon as pyodide is up to date.

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
> One problem with having the wheel as part of the doc is that you add a ~6MB wheel on each push to the doc repo.

We could push the wheel artifact to a dedicated organization on anaconda.org instead of shipping it from scikit-learn.org / githhub.io, no?

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
> We could push the wheel artifact to a dedicated organization on anaconda.org instead of shipping it from scikit-learn.org / githhub.io, no?

Yes we could and that's my favourite option, I was mostly responding to Tim about:

> That way we could build those artefacts as part of the docs with the latest version of scikit-learn.

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
> I think the most reasonable way forward is described in https://github.com/scikit-learn/scikit-learn/pull/25887#issuecomment-1514714120.

Yeah, +1 for that. Hopefully, https://github.com/pypa/cibuildwheel/pull/1456 will be done soon and it would be enough to just enable that platform in cibuildwheel. But since currently it's still not possible to upload such wheels to PyPI, +1 for a dedicated organization on anaconda.org. For instance, Numpy is already running CI to build wheels for this platform so they could also upload them there.

Last we checked anaconda.org is still missing the CORS headers necessary to load them on a web page, and there hasn't been progress on it, but I'll try to raise this question with Anaconda people at EuroPython later this month.

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
@ogrisel @glemaitre @betatim @lesteve @rth
pyodide updated its version to 0.24 on 13-September-2023... what else is missing?

Labels: Documentation, Build / CI
The jupyterlite button of scikit-learn.org/stable for 1.3.0 still uses sklearn.__version__ 1.2.2

We probably need to check if there is a new version of pyodide that includes scikit-learn 1.3.0 and then update: `doc/jupyter-lite.json` because the pyodide version is pinned.

I am not sure how to update the release process to avoid this problem in the future but we have a chicken and egg problem.

COMMENT:
We need to open a PR to update the version.

Labels: Documentation, Build / CI
MLPClassifier don't support target with multiclass-multioutput input.

### Describe the workflow you want to enable

I once expanded my [software](https://pypi.org/project/perming/)'s algorithm input datatype and found that it did not support multiclass-multioutput in the main algorithm (similar to [MLPClassifier in sklearn](https://github.com/scikit-learn/scikit-learn/blob/2a2772a87b6c772dc3b8292bcffb990ce27515a8/sklearn/neural_network/_multilayer_perceptron.py#L759C2-L759C2)). Therefore, I integrated continuous-multioutput, multilabel-indicator, and all target inputs with dimension at 2d into the algorithm.

```python
import perming # v1.3.0
main = perming.Box(10, 3, (30,), batch_size=16, activation='relu', inplace_on=True, solver='sgd', criterion="MultiLabelSoftMarginLoss", learning_rate_init=0.01)
main.data_loader(X, y, random_seed=0) # support multioutput with inner configured criterion and type_of_target
main.train_val(num_epochs=20, interval=10)
main.test()
main.model(X) # X format as torch.Tensor with torch.device("cuda")
```
I use [is_target_2d](https://github.com/linjing-lab/easy-pytorch/blob/769b015f7afb388997c2a6ee1caae9eebe9c648a/released_box/perming/_utils.py#L169) to detect the type_of_target to support any 2d input coordinated with inner criterion and outer bi-directional transform, like *fit_transform* and *inverse_transform*. 

### Describe your proposed solution

I think `LabelBinarizer` in `preprocessing/_label` should not be so robust that use *'multioutput' in self.y_type_* to filter `continuous/multiclass-multioutput`, multilabel is restricted in the *transform* module due to the marking of `str` named *y_type_* and *y_is_multilabel* with [output](https://github.com/scikit-learn/scikit-learn/blob/14995509a996ff5575c032fb7aead25bf6bb595c/sklearn/preprocessing/_label.py#L353) -> **The object was not fitted with multilabel input**.

### Describe alternatives you've considered, if relevant

I found multiclass.py and multioutput.py in the first level of scikit-learn organizational structure, and I wonder whether these two additional files supported algorithms can handle almost all supervised learning datasets that conform to type_of_target.

### Additional context

_No response_

COMMENT:
I'm not sure if I understand the issue here. Could you please post a reproducible code resulting in the issue? It should be a small piece of code which we can copy/paste and reproduce the issue.

Labels: New Feature, Needs Reproducible Code
MLPClassifier don't support target with multiclass-multioutput input.

### Describe the workflow you want to enable

I once expanded my [software](https://pypi.org/project/perming/)'s algorithm input datatype and found that it did not support multiclass-multioutput in the main algorithm (similar to [MLPClassifier in sklearn](https://github.com/scikit-learn/scikit-learn/blob/2a2772a87b6c772dc3b8292bcffb990ce27515a8/sklearn/neural_network/_multilayer_perceptron.py#L759C2-L759C2)). Therefore, I integrated continuous-multioutput, multilabel-indicator, and all target inputs with dimension at 2d into the algorithm.

```python
import perming # v1.3.0
main = perming.Box(10, 3, (30,), batch_size=16, activation='relu', inplace_on=True, solver='sgd', criterion="MultiLabelSoftMarginLoss", learning_rate_init=0.01)
main.data_loader(X, y, random_seed=0) # support multioutput with inner configured criterion and type_of_target
main.train_val(num_epochs=20, interval=10)
main.test()
main.model(X) # X format as torch.Tensor with torch.device("cuda")
```
I use [is_target_2d](https://github.com/linjing-lab/easy-pytorch/blob/769b015f7afb388997c2a6ee1caae9eebe9c648a/released_box/perming/_utils.py#L169) to detect the type_of_target to support any 2d input coordinated with inner criterion and outer bi-directional transform, like *fit_transform* and *inverse_transform*. 

### Describe your proposed solution

I think `LabelBinarizer` in `preprocessing/_label` should not be so robust that use *'multioutput' in self.y_type_* to filter `continuous/multiclass-multioutput`, multilabel is restricted in the *transform* module due to the marking of `str` named *y_type_* and *y_is_multilabel* with [output](https://github.com/scikit-learn/scikit-learn/blob/14995509a996ff5575c032fb7aead25bf6bb595c/sklearn/preprocessing/_label.py#L353) -> **The object was not fitted with multilabel input**.

### Describe alternatives you've considered, if relevant

I found multiclass.py and multioutput.py in the first level of scikit-learn organizational structure, and I wonder whether these two additional files supported algorithms can handle almost all supervised learning datasets that conform to type_of_target.

### Additional context

_No response_

COMMENT:
One possible solution is to use the MultiOutputClassifier class from scikit-learn, which allows you to extend any classifier to handle multioutput classification. This strategy involves fitting one classifier per target variable. Here's an example of how you can use MultiOutputClassifier with the K-nearest neighbors (KNN) classifier:

from sklearn.multioutput import MultiOutputClassifier
from sklearn.neighbors import KNeighborsClassifier

knn = KNeighborsClassifier(n_neighbors=3)
classifier = MultiOutputClassifier(knn, n_jobs=-1)
classifier.fit(X, Y)
predictions = classifier.predict(X)

Labels: New Feature, Needs Reproducible Code
MLPClassifier don't support target with multiclass-multioutput input.

### Describe the workflow you want to enable

I once expanded my [software](https://pypi.org/project/perming/)'s algorithm input datatype and found that it did not support multiclass-multioutput in the main algorithm (similar to [MLPClassifier in sklearn](https://github.com/scikit-learn/scikit-learn/blob/2a2772a87b6c772dc3b8292bcffb990ce27515a8/sklearn/neural_network/_multilayer_perceptron.py#L759C2-L759C2)). Therefore, I integrated continuous-multioutput, multilabel-indicator, and all target inputs with dimension at 2d into the algorithm.

```python
import perming # v1.3.0
main = perming.Box(10, 3, (30,), batch_size=16, activation='relu', inplace_on=True, solver='sgd', criterion="MultiLabelSoftMarginLoss", learning_rate_init=0.01)
main.data_loader(X, y, random_seed=0) # support multioutput with inner configured criterion and type_of_target
main.train_val(num_epochs=20, interval=10)
main.test()
main.model(X) # X format as torch.Tensor with torch.device("cuda")
```
I use [is_target_2d](https://github.com/linjing-lab/easy-pytorch/blob/769b015f7afb388997c2a6ee1caae9eebe9c648a/released_box/perming/_utils.py#L169) to detect the type_of_target to support any 2d input coordinated with inner criterion and outer bi-directional transform, like *fit_transform* and *inverse_transform*. 

### Describe your proposed solution

I think `LabelBinarizer` in `preprocessing/_label` should not be so robust that use *'multioutput' in self.y_type_* to filter `continuous/multiclass-multioutput`, multilabel is restricted in the *transform* module due to the marking of `str` named *y_type_* and *y_is_multilabel* with [output](https://github.com/scikit-learn/scikit-learn/blob/14995509a996ff5575c032fb7aead25bf6bb595c/sklearn/preprocessing/_label.py#L353) -> **The object was not fitted with multilabel input**.

### Describe alternatives you've considered, if relevant

I found multiclass.py and multioutput.py in the first level of scikit-learn organizational structure, and I wonder whether these two additional files supported algorithms can handle almost all supervised learning datasets that conform to type_of_target.

### Additional context

_No response_

COMMENT:
The MLP is included in scikit-learn mostly for educational purposes. For any real usecase you should use other more suitable models such has `HistGradientBoostingClassifier`. We won't be adding more features to the MLP class.

If you really need a neural network model, you can instead use scikeras or skorch to have a scikit-learn compatible model inside your scikit-learn pipeline.

Labels: New Feature, Needs Reproducible Code
⚠️ CI failed on macos_arm64_wheel ⚠️

**CI is still failing on [macos_arm64_wheel](https://cirrus-ci.com/build/6005263916859392)** (Jul 12, 2023)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://cirrus-ci.com/build/6738937880772608) on Jul 17, 2023

Labels: Needs Triage
⚠️ CI failed on macos_arm64_wheel ⚠️

**CI is still failing on [macos_arm64_wheel](https://cirrus-ci.com/build/6005263916859392)** (Jul 12, 2023)

COMMENT:
Note: scipy 1.11.0 was recently yanked and instead scipy 1.11.1 was released instead:

- https://pypi.org/project/scipy/#history

Labels: Needs Triage
⚠️ CI failed on macos_arm64_wheel ⚠️

**CI is still failing on [macos_arm64_wheel](https://cirrus-ci.com/build/6005263916859392)** (Jul 12, 2023)

COMMENT:
> I am confused by the "CI is no longer failing!" comment above. The linked cirrus ci run is still failing:

I found out the cause of this issue and currently coming up with a fix.

Labels: Needs Triage
⚠️ CI failed on macos_arm64_wheel ⚠️

**CI is still failing on [macos_arm64_wheel](https://cirrus-ci.com/build/6005263916859392)** (Jul 12, 2023)

COMMENT:
I opened https://github.com/scikit-learn/scikit-learn/pull/26849 resolved the CirrusCI issue. As for this specific issue, the ARM wheel builds are are passing.

Labels: Needs Triage
KDtree.valid_metrics is no longer an attribute without warning

### Describe the bug

Prior 1.3.0, `KDtree.valid_metrics` was an attribute returning a list. This was also mentioned in the docs as showed in 
https://github.com/scikit-learn/scikit-learn/issues/25364#issuecomment-1379799279. In 1.3.0, however, #25482 added a new method `KDtree.valid_metrics()`, therefore checks like `metric in  KDtree.valid_metrics` does not work anymore. 

From the perspective of our downstream project, this is an unexpected change of behaviour. I don't think that there's anything we can do about it now but it is a bit unfortunate. 

I wanted to open the issue to ensure the team is aware of it but given the situation I don't really expect a fix, unless you have some great idea how to resolve it.

### Steps/Code to Reproduce

```py
from sklearn.neighbors import KDTree

KDTree.valid_metrics
```

### Expected Results

```
['euclidean',
 'l2',
 'minkowski',
 'p',
 'manhattan',
 'cityblock',
 'l1',
 'chebyshev',
 'infinity']
```

We got a list directly before. Now, we have to use `KDTree.valid_metrics()`.

### Actual Results

`<function KDTree.valid_metrics>`

### Versions

```shell
System:
    python: 3.11.4 | packaged by conda-forge | (main, Jun 10 2023, 18:08:41) [Clang 15.0.7 ]
executable: /Users/martin/mambaforge/envs/pointpats_dev/bin/python
   machine: macOS-13.4-arm64-arm-64bit

Python dependencies:
      sklearn: 1.3.0
          pip: 23.0.1
   setuptools: 67.4.0
        numpy: 1.24.4
        scipy: 1.11.0
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.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/martin/mambaforge/envs/pointpats_dev/lib/libopenblas.0.dylib
        version: 0.3.21
threading_layer: openmp
   architecture: VORTEX
    num_threads: 8

       user_api: openmp
   internal_api: openmp
         prefix: libomp
       filepath: /Users/martin/mambaforge/envs/pointpats_dev/lib/libomp.dylib
        version: None
    num_threads: 8
```

COMMENT:
This is unfortunate. @jjerphan do you think we could still expose this an attribute using a property instead of a method to restore backward compat in 1.3.1?

Labels: Bug, Regression
KDtree.valid_metrics is no longer an attribute without warning

### Describe the bug

Prior 1.3.0, `KDtree.valid_metrics` was an attribute returning a list. This was also mentioned in the docs as showed in 
https://github.com/scikit-learn/scikit-learn/issues/25364#issuecomment-1379799279. In 1.3.0, however, #25482 added a new method `KDtree.valid_metrics()`, therefore checks like `metric in  KDtree.valid_metrics` does not work anymore. 

From the perspective of our downstream project, this is an unexpected change of behaviour. I don't think that there's anything we can do about it now but it is a bit unfortunate. 

I wanted to open the issue to ensure the team is aware of it but given the situation I don't really expect a fix, unless you have some great idea how to resolve it.

### Steps/Code to Reproduce

```py
from sklearn.neighbors import KDTree

KDTree.valid_metrics
```

### Expected Results

```
['euclidean',
 'l2',
 'minkowski',
 'p',
 'manhattan',
 'cityblock',
 'l1',
 'chebyshev',
 'infinity']
```

We got a list directly before. Now, we have to use `KDTree.valid_metrics()`.

### Actual Results

`<function KDTree.valid_metrics>`

### Versions

```shell
System:
    python: 3.11.4 | packaged by conda-forge | (main, Jun 10 2023, 18:08:41) [Clang 15.0.7 ]
executable: /Users/martin/mambaforge/envs/pointpats_dev/bin/python
   machine: macOS-13.4-arm64-arm-64bit

Python dependencies:
      sklearn: 1.3.0
          pip: 23.0.1
   setuptools: 67.4.0
        numpy: 1.24.4
        scipy: 1.11.0
       Cython: None
       pandas: 2.0.3
   matplotlib: 3.7.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/martin/mambaforge/envs/pointpats_dev/lib/libopenblas.0.dylib
        version: 0.3.21
threading_layer: openmp
   architecture: VORTEX
    num_threads: 8

       user_api: openmp
   internal_api: openmp
         prefix: libomp
       filepath: /Users/martin/mambaforge/envs/pointpats_dev/lib/libomp.dylib
        version: None
    num_threads: 8
```

COMMENT:
This is indeed an unfortunate regression. IIRC, we wanted to better document the access to valid metrics, but this is in fact a API breaking change.

I think we should revert to the previous behavior and https://github.com/scikit-learn/scikit-learn/pull/26754 has been opened in this regard.

Labels: Bug, Regression