Talip7/scikit-learn-issues-multilabel huggingface dataset:
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
I think this is reasonable. I like the user experience of switching over to `GroupKFold` if `groups` is provided:

https://github.com/scikit-learn/scikit-learn/blob/e653ac6da08a78a3a9b57b7e4fd77af3e1327c5a/sklearn/preprocessing/_target_encoder.py#L270-L275

The `cv` parameter in `TargetEncoder` is restricted to ints to enforce non-overlapping splits.

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
Hi @MatthiasLoefflerQC @thomasjpfan @ogrisel,

I’d be happy to contribute an implementation of the proposed groups parameter for TargetEncoder. The plan would be:
- Add an optional groups argument.
- If provided, switch to GroupKFold; otherwise fall back to current KFold / StratifiedKFold.
- Update docstring and add tests to ensure correct behavior with and without groups.

Would you (and the maintainers) be open to me preparing a PR for this? Happy to iterate based on feedback.

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
Feel free to open a PR @samruddhibaviskar11 , but also note our automated contributions policy: https://scikit-learn.org/dev/developers/contributing.html#automated-contributions-policy

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
can i work on this

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
Hi @MatthiasLoefflerQC, @thomasjpfan, @ogrisel,

I’d like to work on this issue and implement the optional groups parameter for TargetEncoder. The plan is to:

Add an optional groups argument to the fit method.

Switch to GroupKFold if groups is provided, otherwise keep the current KFold / StratifiedKFold logic.

Update the docstring to explain the new groups argument.

Add tests to verify correct behavior both with and without groups.

Please let me know if you have any feedback before I start the PR.

Thanks!

— Nithish

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
Looking at this again, `TargetEncoder` already takes a `cv` parameter. I think a better approach would be to simply accept a `GroupKFold` (or any other splitter), and make sure `fit` and `fit_transform` accept `kwargs` to route to the underlying CV object. This would be a much harder task and sadly I don't think it's a good place for you to handle @nithish-74 .

Maybe @StefanieSenger would like to have a look.

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
Thanks for the clarification @adrinjalali! That makes sense.  

Since this seems to be a bigger change than I initially thought, could you suggest a more beginner-friendly issue for me to get started with? I’d love to contribute and learn my way into the codebase.  

— Nithish

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
> I think a better approach would be to simply accept a GroupKFold

`TargetEncoder` does not accept a generic `cv` object because of this comment:

https://github.com/scikit-learn/scikit-learn/blob/e653ac6da08a78a3a9b57b7e4fd77af3e1327c5a/sklearn/preprocessing/_target_encoder.py#L267-L269

An alternative is to allow for a finite set of splitters (which includes `GroupKFold`)

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
Hi @adrinjalali  @thomasjpfan thanks for the clarification!

I’ve already started working on this PR — could you please confirm if this finite set of splitters approach is the right direction before I proceed further?

Thanks!

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
@thomasjpfan I think it'd make more sense then to get the cv indices, and check for overlap, and raise if the condition is not satisfied. We should be checking for the thing we actually care for, instead of not allowing arbitrary CV objects. WDYT?

Labels: Enhancement, help wanted
```TargetEncoder``` should take ```groups``` as an argument

### Describe the workflow you want to enable

The current implementation of TargetEncoder uses ```KFold```-cross-validation to avoid data leakage. In cases of longitudinal or clustered data, it is desirable to ensure that rows belonging to the same group or cluster belong to the same train-folds to avoid data-leakage.

### Describe your proposed solution

 This could be achieved by introducing an optional```group``` parameter and the use of ```GroupKFold```-cross-validation if the ```group``` is not ```None```.

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

The alternative is to continue ignoring group structure. 


### Additional context

_No response_

COMMENT:
> I think it'd make more sense then to get the cv indices, and check for overlap, and raise if the condition is not satisfied. 

I'm onboard as long as we only do the check for splitters that are not part of an approved list. (`KFold`, `StratifiedKFold`, etc) I do not want to add more overhead for splitters that will not overlap.

Labels: Enhancement, help wanted
RFC new fitted attributes for LogisticRegressionCV

Contributes to #11865.

### Fitted Attributes
After the removal of `multi_class` and any OvR-logic in `LogisticRegressionCV` in #32073, there are a few fitted attributes that have now (or always had) a strange data format (I neglect l1_ratios in the following for ease of reading):
- `coefs_paths_` is a dictionary with class labels as keys and arrays of shape (n_folds, n_cs, n_features) or similar as values.
  As `coef_` is an array of shape (n_classes, n_features), `coefs_paths_` should be an array of shape (n_folds, n_cs, n_classes, n_features), such that `coefs_paths_[idx_fold, idx_cs, :, :]` gives comparable coefficients. Maybe the intercept should be separated as `intercepts_paths_`.
- `scores_` is a dictionary with class labels as keys and arrays of shape (n_folds, n_cs) or similar as values. All values are the same regardless of the key (class label). This is a relict from OvR.
  A good value would be just an array of shape (n_folds, n_cs)
- `C_` is an array of shape (n_classes)
  As the different penalties for classes are gone with the removal of OvR, `C_` should be a single float: the single best penalty parameter.
- `l1_ratio_` same as `C_`
- `n_iter_` is an array of shape (1, n_folds, n_cs) or similar
  The first dimension should be removed, i.e. shape (n_folds, n_cs)

### Deprecation strategy
It is unclear to me how to accomplish the above. Options:
1. Deprecate old attributes and introduce new ones with new names. (time = 2 releases)
2. Same as 1. but then deprecate new ones and reintroduce the old names. (time = 4 releases)
3. Deprecate old attributes and switch behavior in after the deprecation cycle (time = 2 releases)
4. Another option?

Usually, we avoided deprecations options like 3.
@scikit-learn/core-devs recall for comments

COMMENT:
After the removal of `multi-class`, it doesn't make sense to keep the fitted attributes as arrays with repeated columns or arrays with an extra dimension.
Regarding `coefs_paths_` I agree that a shape of (n_folds, n_cs, n_classes, n_features) feels a lot more natural and ease indexing so I'm +1.

Regarding the deprecation cycle, ideally we would have started it at the same time as the deprecation of `multi-class` but we (at least I) didn't anticipate that at the time.

The strategy we usually use in that case is 
```
4. Introduce a new init parameter like `use_legacy_attributes` or something which dictates the behavior of the fitted attributes.
    It's True by default at the beginning, with a warning saying that the default will change to False and that the legacy behavior will be removed in 2 releases.
    In 2 releases, we change the default and deprecate the parameter. We also remove the legacy behavior.
    In 4 releases, we remove the deprecated parameter.
```
It's a 4 releases cycle but the 2nd cycle is just about a useless parameter so very light.

Labels: RFC
RFC new fitted attributes for LogisticRegressionCV

Contributes to #11865.

### Fitted Attributes
After the removal of `multi_class` and any OvR-logic in `LogisticRegressionCV` in #32073, there are a few fitted attributes that have now (or always had) a strange data format (I neglect l1_ratios in the following for ease of reading):
- `coefs_paths_` is a dictionary with class labels as keys and arrays of shape (n_folds, n_cs, n_features) or similar as values.
  As `coef_` is an array of shape (n_classes, n_features), `coefs_paths_` should be an array of shape (n_folds, n_cs, n_classes, n_features), such that `coefs_paths_[idx_fold, idx_cs, :, :]` gives comparable coefficients. Maybe the intercept should be separated as `intercepts_paths_`.
- `scores_` is a dictionary with class labels as keys and arrays of shape (n_folds, n_cs) or similar as values. All values are the same regardless of the key (class label). This is a relict from OvR.
  A good value would be just an array of shape (n_folds, n_cs)
- `C_` is an array of shape (n_classes)
  As the different penalties for classes are gone with the removal of OvR, `C_` should be a single float: the single best penalty parameter.
- `l1_ratio_` same as `C_`
- `n_iter_` is an array of shape (1, n_folds, n_cs) or similar
  The first dimension should be removed, i.e. shape (n_folds, n_cs)

### Deprecation strategy
It is unclear to me how to accomplish the above. Options:
1. Deprecate old attributes and introduce new ones with new names. (time = 2 releases)
2. Same as 1. but then deprecate new ones and reintroduce the old names. (time = 4 releases)
3. Deprecate old attributes and switch behavior in after the deprecation cycle (time = 2 releases)
4. Another option?

Usually, we avoided deprecations options like 3.
@scikit-learn/core-devs recall for comments

COMMENT:
@jeremiedbb I opened #32114 to implement your option 4. Best if it gets shipped with the next (minor) release 1.8.

Labels: RFC
LogisticRegressionCV intercept is wrong

### Describe the bug

The intercept calculated by `LogisticRegressionCV` is wrong.
A bit related to #11865.

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression, LogisticRegressionCV
from sklearn.model_selection import StratifiedKFold

iris = load_iris()
X, y = iris.data, iris.target
lrcv = LogisticRegressionCV(solver="newton-cholesky").fit(X, y)

# exact same split as default LogisticRegressionCV
cv = StratifiedKFold(5)
folds = list(cv.split(X, y))

# First fold (index 0) and second C (index 1)
train_fold_0 = folds[0][0]
lr = LogisticRegression(
    solver="newton-cholesky", C=lrcv.Cs_[1]
).fit(X[train_fold_0], y[train_fold_0])

# Compare coefficients without intercept for class 0
np.testing.assert_allclose(lrcv.coefs_paths_[0][0, 1, :-1], lr.coef_[0], rtol=1e-5)

# Now the intercept of class 0
np.testing.assert_allclose(lrcv.coefs_paths_[0][0, 1, -1], lr.intercept_[0], rtol=1e-5)
```

It is also not related to the freedom to add a constant to coefficients: Probabilities are invariant under shifting all coefficients of a single feature j for all classes by the same amount c:
`coef[k, :] -> coef[k, :] + c    =>    proba stays the same`
See
```python
# Intercept for all classes
lr.intercept_
# array([ 0.35141429, -0.02662967, -0.32478462])

[lrcv.coefs_paths_[cla][0, 1, -1] for cla in range(3)]
# [0.33603135678054513, -0.04201515149357693, -0.2940162052869682]
# These are not related by a single constant.
```

### Expected Results

The `LogisticRegression` should reproduce the same result as the selected on from `LogisticRegressionCV`.

### Actual Results

AssertionError: 
Not equal to tolerance rtol=1e-05, atol=0

Mismatched elements: 1 / 1 (100%)
Max absolute difference among violations: 0.01538293
Max relative difference among violations: 0.04377435
 ACTUAL: array(0.336031)
 DESIRED: array(0.351414)


### Versions

```shell
System:
    python: 3.12.9 (main, Feb  4 2025, 14:38:38) [Clang 16.0.0 (clang-1600.0.26.6)]
executable: .../bin/python
   machine: macOS-15.6.1-x86_64-i386-64bit

Python dependencies:
      sklearn: 1.7.1
          pip: 25.1.1
   setuptools: 77.0.3
        numpy: 2.1.3
        scipy: 1.15.3
       Cython: 3.0.12
       pandas: 2.2.3
   matplotlib: 3.10.1
       joblib: 1.4.2
threadpoolctl: 3.6.0

Built with OpenMP: True

threadpoolctl info:
       user_api: openmp
   internal_api: openmp
    num_threads: 8
         prefix: libomp
       filepath: .../lib/python3.12/site-packages/sklearn/.dylibs/libomp.dylib
        version: None
```

COMMENT:
This is in fact a duplicate of #31859 which was already fixed on main.

Labels: Bug, Needs Triage
Enhance the warning message for metadata default value change

### Describe the workflow you want to enable

Currently the warning raised for [Deprecation / Default Value Change](https://scikit-learn.org/stable/auto_examples/miscellaneous/plot_metadata_routing.html#deprecation-default-value-change)
is quite generic
```
Support for sample_weight has recently been added to this class. To maintain backward compatibility, ...
```

Would it be possible to specify the class in question ?  Something like
```
Support for sample_weight has recently been added to ExampleRegressor. To maintain backward compatibility, ...
```

### Describe your proposed solution

I think we can get the class through the owner attribute of the MethodMetadataRequest which raises the warning.

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

_No response_

### Additional context

_No response_

COMMENT:
Yes, "this" has always been confusing :) Anyway, just a small PR #32070  to fix it

Labels: New Feature, Needs Triage
Regressor Prediction Makes a Negative Y Offset

### Describe the bug

Hi, I've found a strange situation where regressor prediction makes a negative Y offset. See an orange line on my picture below.
Here is my py file and json data:
[test_scikit.zip](https://github.com/user-attachments/files/22069020/test_scikit.zip)

You will need to change JS_PATH  to your path:
JS_PATH = "D:/Projects/Crpt/CryptoMaiden/Bot/Base/Test/btc_data.json"

You will also need to install a poltly lib.

<img width="1625" height="921" alt="Image" src="https://github.com/user-attachments/assets/e8ac2c73-c556-4570-be28-6bfaedd7ba82" />

I'm new to the Scikit so I decided to report the issue.

I tried RandomForestRegressor, AdaBoostRegressor, GradientBoostingRegressor, HistGradientBoostingRegressor and all of them have this issue. 
To change a regressor in my code you can just comment/uncomment it on lines 89-95.

### Steps/Code to Reproduce

# See my attached ZIP file!

### Expected Results

No negative Y offset.

### Actual Results

Just run my py file!

### Versions

```shell
1.7.1
```

COMMENT:
It seems Classifiers have the same problem. I've attached another one example (ZIP file):
[test_scikit_2.zip](https://github.com/user-attachments/files/22069131/test_scikit_2.zip)

<img width="1535" height="905" alt="Image" src="https://github.com/user-attachments/assets/34091487-a0fc-40b3-a539-4a7db05030a7" />

Labels: Bug, Needs Investigation
Regressor Prediction Makes a Negative Y Offset

### Describe the bug

Hi, I've found a strange situation where regressor prediction makes a negative Y offset. See an orange line on my picture below.
Here is my py file and json data:
[test_scikit.zip](https://github.com/user-attachments/files/22069020/test_scikit.zip)

You will need to change JS_PATH  to your path:
JS_PATH = "D:/Projects/Crpt/CryptoMaiden/Bot/Base/Test/btc_data.json"

You will also need to install a poltly lib.

<img width="1625" height="921" alt="Image" src="https://github.com/user-attachments/assets/e8ac2c73-c556-4570-be28-6bfaedd7ba82" />

I'm new to the Scikit so I decided to report the issue.

I tried RandomForestRegressor, AdaBoostRegressor, GradientBoostingRegressor, HistGradientBoostingRegressor and all of them have this issue. 
To change a regressor in my code you can just comment/uncomment it on lines 89-95.

### Steps/Code to Reproduce

# See my attached ZIP file!

### Expected Results

No negative Y offset.

### Actual Results

Just run my py file!

### Versions

```shell
1.7.1
```

COMMENT:
According to me, the negative Y-offset isn’t a bug in scikit-learn/XGBoost, it comes from target alignment and plotting. The target_return needed to be shifted so each bar’s return is predicted from the previous bar’s features, and the plot was missing the actual returns trace. After adding df_test["target_return"] to the chart and fixing the alignment, the predictions should line up correctly

https://colab.research.google.com/drive/1tW_KmU5grPz9u5nkP4FAjfSRgLj5mbtN?usp=sharing

Labels: Bug, Needs Investigation