Talip7/scikit-learn-issues-multilabel huggingface dataset:
Callback API plan

The goal of this issue is to track the steps of the implementation of a callback API in scikit-learn.

This is being developed in the `callbacks` feature branch. The first PR to this branch is https://github.com/scikit-learn/scikit-learn/pull/27663 which implements the base infrastructure for the callbacks and a first callback (progress bars). Subsequent PRs will add more callbacks, mode doc, more tests, adapt estimators to support callbacks, ...

- [ ] Base infrastructure https://github.com/scikit-learn/scikit-learn/pull/27663

**Callbacks**
- [ ] Progress bars https://github.com/scikit-learn/scikit-learn/pull/27663
- [ ] Monitoring
- [ ] EarlyStopping
- [ ] Snapshots
- [ ] Verbose / Logging

**Doc**
- [ ] examples
- [ ] how to write a custom callback

**Adapt estimators**
*full list incoming*

COMMENT:
hey, i'd like to take up this issue

Labels: Meta-issue
`sklearn.cluster.AgglomerativeClustering`: allow `'ward'` linkage and `'precomputed'` metric.

Hi,

I'm trying to run `AgglomerativeClustering` with precomputed (Euclidean) distance matrices. However, I can't get it to work with `linkage='ward'` and `metric='precomputed'` due to this `ValueError`:

https://github.com/scikit-learn/scikit-learn/blob/1f1329f7ecb001eda2ff8e6d6a68bc2054c4962f/sklearn/cluster/_agglomerative.py#L1029-L1033

Would you consider a PR making this into a warning when `metric='precomputed'`? This would allow passing precomputed distance matrices to the Ward method.

Thank you,
Vini

COMMENT:
This seems like a legitimate use case. I don't think that we should be warning because we are going to throw too many false positive warning even if the code is correct.

I think that we should only mention in the documentation that no check will be performed on the precomputed matrix when we are in this combination.

@vinisalazar Feel free to make a pull-request to let pass this case without error. We will also need a unit test to cover this use case.

Labels: Enhancement
`sklearn.cluster.AgglomerativeClustering`: allow `'ward'` linkage and `'precomputed'` metric.

Hi,

I'm trying to run `AgglomerativeClustering` with precomputed (Euclidean) distance matrices. However, I can't get it to work with `linkage='ward'` and `metric='precomputed'` due to this `ValueError`:

https://github.com/scikit-learn/scikit-learn/blob/1f1329f7ecb001eda2ff8e6d6a68bc2054c4962f/sklearn/cluster/_agglomerative.py#L1029-L1033

Would you consider a PR making this into a warning when `metric='precomputed'`? This would allow passing precomputed distance matrices to the Ward method.

Thank you,
Vini

COMMENT:
Working on this with @papjuli

Labels: Enhancement
`sklearn.cluster.AgglomerativeClustering`: allow `'ward'` linkage and `'precomputed'` metric.

Hi,

I'm trying to run `AgglomerativeClustering` with precomputed (Euclidean) distance matrices. However, I can't get it to work with `linkage='ward'` and `metric='precomputed'` due to this `ValueError`:

https://github.com/scikit-learn/scikit-learn/blob/1f1329f7ecb001eda2ff8e6d6a68bc2054c4962f/sklearn/cluster/_agglomerative.py#L1029-L1033

Would you consider a PR making this into a warning when `metric='precomputed'`? This would allow passing precomputed distance matrices to the Ward method.

Thank you,
Vini

COMMENT:
It seems that [ward_tree](https://github.com/scikit-learn/scikit-learn/blob/1f1329f7ecb001eda2ff8e6d6a68bc2054c4962f/sklearn/cluster/_agglomerative.py#L192) is expecting the sample matrix since [compute_ward_dist](https://github.com/scikit-learn/scikit-learn/blob/02da144bff9521a9b4a683b27e3886f9e8680343/sklearn/cluster/_hierarchical_fast.pyx#L19) is using the sample matrix

Needs further investigation

Labels: Enhancement
`sklearn.cluster.AgglomerativeClustering`: allow `'ward'` linkage and `'precomputed'` metric.

Hi,

I'm trying to run `AgglomerativeClustering` with precomputed (Euclidean) distance matrices. However, I can't get it to work with `linkage='ward'` and `metric='precomputed'` due to this `ValueError`:

https://github.com/scikit-learn/scikit-learn/blob/1f1329f7ecb001eda2ff8e6d6a68bc2054c4962f/sklearn/cluster/_agglomerative.py#L1029-L1033

Would you consider a PR making this into a warning when `metric='precomputed'`? This would allow passing precomputed distance matrices to the Ward method.

Thank you,
Vini

COMMENT:
OK so this is not as straightforward. We probably need to reimplement something compute the ward distance from the a matrix of precomputed distance. I don't know if this is possible.

Labels: Enhancement
`sklearn.cluster.AgglomerativeClustering`: allow `'ward'` linkage and `'precomputed'` metric.

Hi,

I'm trying to run `AgglomerativeClustering` with precomputed (Euclidean) distance matrices. However, I can't get it to work with `linkage='ward'` and `metric='precomputed'` due to this `ValueError`:

https://github.com/scikit-learn/scikit-learn/blob/1f1329f7ecb001eda2ff8e6d6a68bc2054c4962f/sklearn/cluster/_agglomerative.py#L1029-L1033

Would you consider a PR making this into a warning when `metric='precomputed'`? This would allow passing precomputed distance matrices to the Ward method.

Thank you,
Vini

COMMENT:
Hi @glemaitre @mrastgoo, thank you for the comments. I guess this will have to be set aside for now, but please let me know if I can be of any help in the future.

Labels: Enhancement
`sklearn.cluster.AgglomerativeClustering`: allow `'ward'` linkage and `'precomputed'` metric.

Hi,

I'm trying to run `AgglomerativeClustering` with precomputed (Euclidean) distance matrices. However, I can't get it to work with `linkage='ward'` and `metric='precomputed'` due to this `ValueError`:

https://github.com/scikit-learn/scikit-learn/blob/1f1329f7ecb001eda2ff8e6d6a68bc2054c4962f/sklearn/cluster/_agglomerative.py#L1029-L1033

Would you consider a PR making this into a warning when `metric='precomputed'`? This would allow passing precomputed distance matrices to the Ward method.

Thank you,
Vini

COMMENT:
If it can help, in SciPy and only for Euclidean distances (see caveat in [note 2](https://docs.scipy.org/doc/scipy/reference/generated/scipy.cluster.hierarchy.linkage.html)):
```python
linkage_mat = linkage(distance_mat, method='ward')
labels = fcluster(linkage_mat, t=n_clusters, criterion='maxclust')
```

Labels: Enhancement
inverse_transform Xt argument consistency

### Describe the issue linked to the documentation

Some of the inverse_transform methods take `Xt` as an argument whereas others take `X`. Is there are reason for the differences in the names?

Noting the cases here: https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn%20%22def%20inverse_transform%22&type=code

### Suggest a potential alternative/fix

Stick to `Xt` in all cases

COMMENT:
@wd60622 JTBC you recommend refactoring all `inverse_transform` args `X` --> `Xt`?

Labels: API
inverse_transform Xt argument consistency

### Describe the issue linked to the documentation

Some of the inverse_transform methods take `Xt` as an argument whereas others take `X`. Is there are reason for the differences in the names?

Noting the cases here: https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn%20%22def%20inverse_transform%22&type=code

### Suggest a potential alternative/fix

Stick to `Xt` in all cases

COMMENT:
> @wd60622 JTBC you recommend refactoring all `inverse_transform` args `X` --> `Xt`?

Yes. I read `Xt` as the result of `something.transform(X)`, so `X = something.inverse_transform(Xt)`. However, a simple renaming could break a lot of code. But it would provide a standard interface for the `inverse_transform` method. 

```python 
# Has Xt arg
pipeline = make_pipeline(StandardScaler())
Xt = pipeline.fit_transform(X)
X_again = pipeline.inverse_transform(Xt=Xt)

# inverse_transform takes X instead of Xt
transformer = StandardScaler()
Xt = transformer.fit_transform(X)
X_again = transformer.inverse_transform(Xt=Xt)
# TypeError: inverse_transform() got an unexpected keyword argument 'Xt'

Labels: API
inverse_transform Xt argument consistency

### Describe the issue linked to the documentation

Some of the inverse_transform methods take `Xt` as an argument whereas others take `X`. Is there are reason for the differences in the names?

Noting the cases here: https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn%20%22def%20inverse_transform%22&type=code

### Suggest a potential alternative/fix

Stick to `Xt` in all cases

COMMENT:
I think that we got a similar refactoring to replace `Y` by `y` for consistency (https://github.com/scikit-learn/scikit-learn/pull/27666). So I am fine with carrying on this deprecation.

Labels: API
inverse_transform Xt argument consistency

### Describe the issue linked to the documentation

Some of the inverse_transform methods take `Xt` as an argument whereas others take `X`. Is there are reason for the differences in the names?

Noting the cases here: https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn%20%22def%20inverse_transform%22&type=code

### Suggest a potential alternative/fix

Stick to `Xt` in all cases

COMMENT:
> I think that we got a similar refactoring to replace `Y` by `y` for consistency (#27666). So I am fine with carrying on this deprecation.

Nice, thanks for clarifying. If I can help out in anyway, I'll gladly make a PR

Labels: API
inverse_transform Xt argument consistency

### Describe the issue linked to the documentation

Some of the inverse_transform methods take `Xt` as an argument whereas others take `X`. Is there are reason for the differences in the names?

Noting the cases here: https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn%20%22def%20inverse_transform%22&type=code

### Suggest a potential alternative/fix

Stick to `Xt` in all cases

COMMENT:
Feel free to make a PR. You can check how this is handled in the other PR to know how to deprecate `Xt` without throwing too many warnings.

Labels: API
inverse_transform Xt argument consistency

### Describe the issue linked to the documentation

Some of the inverse_transform methods take `Xt` as an argument whereas others take `X`. Is there are reason for the differences in the names?

Noting the cases here: https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn%20%22def%20inverse_transform%22&type=code

### Suggest a potential alternative/fix

Stick to `Xt` in all cases

COMMENT:
Conclusion in https://github.com/scikit-learn/scikit-learn/pull/28756#issuecomment-2040073727 and following comments:
We want the argument if inverse transform to be X and make it happen by the standard deprecation (deprecate in version 1.x, remove deprecation and carry out the final change in 1.x+2).

Labels: API
scikit-learn-1.3.2.tar.gz archive contains version 1.4.dev0

### Describe the bug

The package downloaded from [https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz](https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz)
contains version 1.4.dev0:

The file `sklearn/__init__.py` defines:

```
__version__ = "1.4.dev0"
```


### Steps/Code to Reproduce

Download archive file. Check __init__.py

### Expected Results

Version is 1.3.2 .

### Actual Results

Version is  1.4.dev0

### Versions

```shell
1.3.2
```

COMMENT:
please, Assign this issue to me

Labels: Bug, Needs Triage
scikit-learn-1.3.2.tar.gz archive contains version 1.4.dev0

### Describe the bug

The package downloaded from [https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz](https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz)
contains version 1.4.dev0:

The file `sklearn/__init__.py` defines:

```
__version__ = "1.4.dev0"
```


### Steps/Code to Reproduce

Download archive file. Check __init__.py

### Expected Results

Version is 1.3.2 .

### Actual Results

Version is  1.4.dev0

### Versions

```shell
1.3.2
```

COMMENT:
The [1.3.1 tag was created on the 1.3.X branch](https://github.com/scikit-learn/scikit-learn/commit/55a65a2fa5653257225d7e184da3d0c00ff852b1) while the [1.3.2 tag is on the main](https://github.com/scikit-learn/scikit-learn/commit/4d6f1c875d413a6b5f2baf3367d4cc4a7bf812e8) branch.  I assume this was not intended.

CC @althonos @glemaitre

Labels: Bug, Needs Triage
scikit-learn-1.3.2.tar.gz archive contains version 1.4.dev0

### Describe the bug

The package downloaded from [https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz](https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz)
contains version 1.4.dev0:

The file `sklearn/__init__.py` defines:

```
__version__ = "1.4.dev0"
```


### Steps/Code to Reproduce

Download archive file. Check __init__.py

### Expected Results

Version is 1.3.2 .

### Actual Results

Version is  1.4.dev0

### Versions

```shell
1.3.2
```

COMMENT:
This was not intended. @rbuffat Thanks for pointing this out.

Labels: Bug, Needs Triage
scikit-learn-1.3.2.tar.gz archive contains version 1.4.dev0

### Describe the bug

The package downloaded from [https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz](https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz)
contains version 1.4.dev0:

The file `sklearn/__init__.py` defines:

```
__version__ = "1.4.dev0"
```


### Steps/Code to Reproduce

Download archive file. Check __init__.py

### Expected Results

Version is 1.3.2 .

### Actual Results

Version is  1.4.dev0

### Versions

```shell
1.3.2
```

COMMENT:
/take

Labels: Bug, Needs Triage
scikit-learn-1.3.2.tar.gz archive contains version 1.4.dev0

### Describe the bug

The package downloaded from [https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz](https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz)
contains version 1.4.dev0:

The file `sklearn/__init__.py` defines:

```
__version__ = "1.4.dev0"
```


### Steps/Code to Reproduce

Download archive file. Check __init__.py

### Expected Results

Version is 1.3.2 .

### Actual Results

Version is  1.4.dev0

### Versions

```shell
1.3.2
```

COMMENT:
OK so we created a new tag to not have a tag pointing on `main`.

Labels: Bug, Needs Triage
scikit-learn-1.3.2.tar.gz archive contains version 1.4.dev0

### Describe the bug

The package downloaded from [https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz](https://github.com/scikit-learn/scikit-learn/archive/1.3.2/scikit-learn-1.3.2.tar.gz)
contains version 1.4.dev0:

The file `sklearn/__init__.py` defines:

```
__version__ = "1.4.dev0"
```


### Steps/Code to Reproduce

Download archive file. Check __init__.py

### Expected Results

Version is 1.3.2 .

### Actual Results

Version is  1.4.dev0

### Versions

```shell
1.3.2
```

COMMENT:
Thanks!

Labels: Bug, Needs Triage
Add individual penalization to precision matrix in graphical_lasso.py

### Describe the workflow you want to enable

Friedman et al. (2008) describe the coordinate descent procedure used for the graphical lasso.
In the paper, there is a REMARK 2.1, which states that the objective function to be optimized can be modified to allow for a matrix of penalty values, rather than a scalar value. 

### Describe your proposed solution

This has been implemented [here](https://github.com/m-barylli/scikit-learn-graphical-lasso-edit/commit/05ed1c63dd2f00bbcffbb59db18833d6748dbd54).
However, linear_model._cd_fast.pyx still has to be updated to allow for vectorized alpha input in enet_coordinate_descent_gram

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

_No response_

### Additional context

This change is motivated to allow for prior incorporation into the inference procedure. When strong priors for edges are available, this can affect the strength of the corresponding edges' penalization.

COMMENT:
I'm new on GitHub but I would like to contribute to this issue if this is possible.

Labels: New Feature, Needs Decision
Add individual penalization to precision matrix in graphical_lasso.py

### Describe the workflow you want to enable

Friedman et al. (2008) describe the coordinate descent procedure used for the graphical lasso.
In the paper, there is a REMARK 2.1, which states that the objective function to be optimized can be modified to allow for a matrix of penalty values, rather than a scalar value. 

### Describe your proposed solution

This has been implemented [here](https://github.com/m-barylli/scikit-learn-graphical-lasso-edit/commit/05ed1c63dd2f00bbcffbb59db18833d6748dbd54).
However, linear_model._cd_fast.pyx still has to be updated to allow for vectorized alpha input in enet_coordinate_descent_gram

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

_No response_

### Additional context

This change is motivated to allow for prior incorporation into the inference procedure. When strong priors for edges are available, this can affect the strength of the corresponding edges' penalization.

COMMENT:
@Dracocybertech Awesome! Here is the link to my fork: https://github.com/m-barylli/scikit-learn-graphical-lasso-edit

If you want to make edits, please refer to this guide: https://scikit-learn.org/stable/developers/advanced_installation.html

Currently, _cd_fast.pyx (Here: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/linear_model/_cd_fast.pyx) needs to be updated according to the changes made in _graph_lasso.py. 

If you are still interested, let me know!

Labels: New Feature, Needs Decision
Add individual penalization to precision matrix in graphical_lasso.py

### Describe the workflow you want to enable

Friedman et al. (2008) describe the coordinate descent procedure used for the graphical lasso.
In the paper, there is a REMARK 2.1, which states that the objective function to be optimized can be modified to allow for a matrix of penalty values, rather than a scalar value. 

### Describe your proposed solution

This has been implemented [here](https://github.com/m-barylli/scikit-learn-graphical-lasso-edit/commit/05ed1c63dd2f00bbcffbb59db18833d6748dbd54).
However, linear_model._cd_fast.pyx still has to be updated to allow for vectorized alpha input in enet_coordinate_descent_gram

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

_No response_

### Additional context

This change is motivated to allow for prior incorporation into the inference procedure. When strong priors for edges are available, this can affect the strength of the corresponding edges' penalization.

COMMENT:
We already discussed the possibility of adding matrix-parameterized regularization to linear models in the pass (I think it was for GLMs with @lorentzenchr and discussed with @agramfort  and at the time we decided that this kind of feature would be outside of the scope of scikit-learn because we would need consistent support for various estimators / solver combinations and it can severely increase the maintenance cost of the library.

Still the code change is not that large in the case of graphical lasso. So I am a bit undecided. But if we decide one way or another we should be consistent.

Labels: New Feature, Needs Decision
Add individual penalization to precision matrix in graphical_lasso.py

### Describe the workflow you want to enable

Friedman et al. (2008) describe the coordinate descent procedure used for the graphical lasso.
In the paper, there is a REMARK 2.1, which states that the objective function to be optimized can be modified to allow for a matrix of penalty values, rather than a scalar value. 

### Describe your proposed solution

This has been implemented [here](https://github.com/m-barylli/scikit-learn-graphical-lasso-edit/commit/05ed1c63dd2f00bbcffbb59db18833d6748dbd54).
However, linear_model._cd_fast.pyx still has to be updated to allow for vectorized alpha input in enet_coordinate_descent_gram

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

_No response_

### Additional context

This change is motivated to allow for prior incorporation into the inference procedure. When strong priors for edges are available, this can affect the strength of the corresponding edges' penalization.

COMMENT:
Related to #11566.

Labels: New Feature, Needs Decision
Sphinx version information in "Building the documentation" section needs reevaluation

### Describe the issue linked to the documentation

At the bottom of the ["Building the documentation" section](https://github.com/scikit-learn/scikit-learn/blob/main/doc/developers/contributing.rst#building-the-documentation) there is a warning about the best performing `sphinx` version, which leads to [this file](https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn+sphinx+path%3Abuild_tools%2Fcircle%2Fdoc_environment.yml&type=code), supposedly mirroring the configuration on `CircleCI`.

In the file, the suggested version is `sphinx=6.0.0`. However, `sphinx=7.0.0` is the minimum necessary to make the current package combination work. If the version is reverted back to `sphinx=6.0.0`, the following error will appear: `sphinx-prompt 1.8.0 requires Sphinx<8.0.0,>=7.0.0, but you have sphinx 6.0.0 which is incompatible`. 

### Suggest a potential alternative/fix

Replace `sphinx=6.0.0` with `sphinx=7.0.0`.

COMMENT:
Thanks for reporting this.

We also have a "minimum versions build" where sphinx 6.0.0 and sphinx-prompt 13 are used together. As there is no version specified for sphinx-prompt I would assume that while solving the various constraints the package manager would select sphinx=6 (because its fixed/selected by the user) and then find the compatible sphinx-prompt version (1.3.0).

Could you explain a bit more how you ended up with sphinx-prompt 1.8.0? Did you select that version? Which tools did you use to set up things (conda, pip, something else)?

Labels: Documentation
Sphinx version information in "Building the documentation" section needs reevaluation

### Describe the issue linked to the documentation

At the bottom of the ["Building the documentation" section](https://github.com/scikit-learn/scikit-learn/blob/main/doc/developers/contributing.rst#building-the-documentation) there is a warning about the best performing `sphinx` version, which leads to [this file](https://github.com/search?q=repo%3Ascikit-learn%2Fscikit-learn+sphinx+path%3Abuild_tools%2Fcircle%2Fdoc_environment.yml&type=code), supposedly mirroring the configuration on `CircleCI`.

In the file, the suggested version is `sphinx=6.0.0`. However, `sphinx=7.0.0` is the minimum necessary to make the current package combination work. If the version is reverted back to `sphinx=6.0.0`, the following error will appear: `sphinx-prompt 1.8.0 requires Sphinx<8.0.0,>=7.0.0, but you have sphinx 6.0.0 which is incompatible`. 

### Suggest a potential alternative/fix

Replace `sphinx=6.0.0` with `sphinx=7.0.0`.

COMMENT:
If you are looking to contribute to scikit-learn, the pragmatic solution is to downgrade sphinx-prompt: `pip install sphinx=6.0 sphinx-prompt`.

I am not sure this is that easy to document because this kind of thing tend to change a lot with time ... we could link to the [lock file](https://github.com/scikit-learn/scikit-learn/blob/main/build_tools/circle/doc_linux-64_conda.lock) we use in the CI since it has all the versions which we use for the CI but this is quite verbose.

This is easy to get into such a situation with pip:

```
# gets sphinx 7.2.6 sphinx-prompt 1.8 (latest releases) 
pip install sphinx sphinx-prompt
```

Oh wait the doc says I need sphinx 6.0:

```
pip install sphinx==6.0
```

At the end of the output you get some kind of warnings that you have incompatible packages but pip still installs them:
```
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
sphinx-prompt 1.8.0 requires Sphinx<8.0.0,>=7.0.0, but you have sphinx 6.0.0 which is incompatible.
Successfully installed sphinx-6.0.0
```

Labels: Documentation