Talip7/scikit-learn-issues-multilabel huggingface dataset:
CI CUDA CI not running in lock-file update automated PR

Discussed in https://github.com/scikit-learn/scikit-learn/pull/29576#issuecomment-2255371442, for now we need to remember to unset "CUDA CI" label and set it again manually on automated array API lock-file PRs like https://github.com/scikit-learn/scikit-learn/pull/29766.

From https://github.com/scikit-learn/scikit-learn/issues/29576#issuecomment-2328452652, maybe this is due to triggering a workflow from a workflow limitations, see [doc](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#triggering-a-workflow-from-a-workflow). Apparently you need a PAT rather than the default GITHUB_TOKEN when you are in this case. The last example in the doc is very similar to our use case I think:

> Conversely, the following workflow uses GITHUB_TOKEN to add a label to an issue. It will not trigger any workflows that run when a label is added.

I don't remember if we have a PAT for some of the CI that we could try to see whether that fixes the issue ...

COMMENT:
/cc @betatim who might also be interested in this discussion.

Labels: Build / CI
CI CUDA CI not running in lock-file update automated PR

Discussed in https://github.com/scikit-learn/scikit-learn/pull/29576#issuecomment-2255371442, for now we need to remember to unset "CUDA CI" label and set it again manually on automated array API lock-file PRs like https://github.com/scikit-learn/scikit-learn/pull/29766.

From https://github.com/scikit-learn/scikit-learn/issues/29576#issuecomment-2328452652, maybe this is due to triggering a workflow from a workflow limitations, see [doc](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#triggering-a-workflow-from-a-workflow). Apparently you need a PAT rather than the default GITHUB_TOKEN when you are in this case. The last example in the doc is very similar to our use case I think:

> Conversely, the following workflow uses GITHUB_TOKEN to add a label to an issue. It will not trigger any workflows that run when a label is added.

I don't remember if we have a PAT for some of the CI that we could try to see whether that fixes the issue ...

COMMENT:
Ah yes, I did not want to give @scikit-learn-bot to have any write permissions. For @scikit-learn-bot's token to have the permissions to add a label we'll need to:

- Give the PAT the `public_repo` permission (I can not find a smaller permission
- Add @scikit-learn-bot to the triage team

Another option is to trigger add `workflow_dispatch` to `.github/workflows/cuda-ci.yml` and trigger it from `.github/workflows/update-lock-files.yml`. (I have not tested this idea, but it should work)

Labels: Build / CI
CI CUDA CI not running in lock-file update automated PR

Discussed in https://github.com/scikit-learn/scikit-learn/pull/29576#issuecomment-2255371442, for now we need to remember to unset "CUDA CI" label and set it again manually on automated array API lock-file PRs like https://github.com/scikit-learn/scikit-learn/pull/29766.

From https://github.com/scikit-learn/scikit-learn/issues/29576#issuecomment-2328452652, maybe this is due to triggering a workflow from a workflow limitations, see [doc](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#triggering-a-workflow-from-a-workflow). Apparently you need a PAT rather than the default GITHUB_TOKEN when you are in this case. The last example in the doc is very similar to our use case I think:

> Conversely, the following workflow uses GITHUB_TOKEN to add a label to an issue. It will not trigger any workflows that run when a label is added.

I don't remember if we have a PAT for some of the CI that we could try to see whether that fixes the issue ...

COMMENT:
From the docs that Loic linked:

> When you use the repository's `GITHUB_TOKEN` to perform tasks, events triggered by the `GITHUB_TOKEN`, with the exception of `workflow_dispatch` and `repository_dispatch`, will not create a new workflow run. 

I think this explains why the label is added but there is no response to the label being added (the workflow doesn't start running).

I am unsure, but think we should not add `workflow_dispatch` to the CUDA CI workflow, even though the docs make me think this would allow a workflow to trigger this workflow. The reason not to add it is that the workflow then runs in the context of `main`, which creates cache poisoning, etc problems.

Labels: Build / CI
CI CUDA CI not running in lock-file update automated PR

Discussed in https://github.com/scikit-learn/scikit-learn/pull/29576#issuecomment-2255371442, for now we need to remember to unset "CUDA CI" label and set it again manually on automated array API lock-file PRs like https://github.com/scikit-learn/scikit-learn/pull/29766.

From https://github.com/scikit-learn/scikit-learn/issues/29576#issuecomment-2328452652, maybe this is due to triggering a workflow from a workflow limitations, see [doc](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#triggering-a-workflow-from-a-workflow). Apparently you need a PAT rather than the default GITHUB_TOKEN when you are in this case. The last example in the doc is very similar to our use case I think:

> Conversely, the following workflow uses GITHUB_TOKEN to add a label to an issue. It will not trigger any workflows that run when a label is added.

I don't remember if we have a PAT for some of the CI that we could try to see whether that fixes the issue ...

COMMENT:
I think the simplest fix is to add `scikit-learn-bot` to the Contributor Experience team so that it has Triage permission and is able to add/remove labels. We can use the same PAT that we are already using which does have the `public_repo` permission.

I think adding scikit-learn-bot Triage rights is not too bad. Going over [Triage permissions](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization#permissions-for-each-role) the worst that could happen (in case scikit-learn-bot was taken over by a malicious actor) is that scikit-learn-bot can be used to:
- set/unset "CUDA CI" label multiple times to mine bitcoins
- close issues/PRs
- hide comments
- plus some special powers for discussions (which we don't use very often) like locking/deleting a discussion (deleting an issue can not be done with only Triage rights just to be 100% explicit)

I have opened https://github.com/scikit-learn/scikit-learn/pull/29994 that uses the already existing PAT token.

If there is no objection, I'll add scikit-learn-bot to the Contributor experience team and if #2994 is merged by next Monday we can see if it actually works on the next automatic lock-file update PRs :crossed_fingers:.

Labels: Build / CI
CI CUDA CI not running in lock-file update automated PR

Discussed in https://github.com/scikit-learn/scikit-learn/pull/29576#issuecomment-2255371442, for now we need to remember to unset "CUDA CI" label and set it again manually on automated array API lock-file PRs like https://github.com/scikit-learn/scikit-learn/pull/29766.

From https://github.com/scikit-learn/scikit-learn/issues/29576#issuecomment-2328452652, maybe this is due to triggering a workflow from a workflow limitations, see [doc](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#triggering-a-workflow-from-a-workflow). Apparently you need a PAT rather than the default GITHUB_TOKEN when you are in this case. The last example in the doc is very similar to our use case I think:

> Conversely, the following workflow uses GITHUB_TOKEN to add a label to an issue. It will not trigger any workflows that run when a label is added.

I don't remember if we have a PAT for some of the CI that we could try to see whether that fixes the issue ...

COMMENT:
Looking at this again, I rather not add a bot account to the contributor experience team. We'll have to special case the bot account in `build_tools/generate_authors_table.py`.

We already have a "Robots team". We can add `scikit-learn-bot` there and give it triage permissions?

Labels: Build / CI
CI CUDA CI not running in lock-file update automated PR

Discussed in https://github.com/scikit-learn/scikit-learn/pull/29576#issuecomment-2255371442, for now we need to remember to unset "CUDA CI" label and set it again manually on automated array API lock-file PRs like https://github.com/scikit-learn/scikit-learn/pull/29766.

From https://github.com/scikit-learn/scikit-learn/issues/29576#issuecomment-2328452652, maybe this is due to triggering a workflow from a workflow limitations, see [doc](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#triggering-a-workflow-from-a-workflow). Apparently you need a PAT rather than the default GITHUB_TOKEN when you are in this case. The last example in the doc is very similar to our use case I think:

> Conversely, the following workflow uses GITHUB_TOKEN to add a label to an issue. It will not trigger any workflows that run when a label is added.

I don't remember if we have a PAT for some of the CI that we could try to see whether that fixes the issue ...

COMMENT:
I have created a Triage robots team with Triage rights and added scikit-learn-bot to it. I think this was the simplest thing to do.

FYI, there was an old Privileged robots (IIRC was needed for LGTM at one point?) and I removed it while I was at it.

Labels: Build / CI
Implementation of fit_transform in ColumnTransformer

In `TransformerMixin`, `fit_transform` is implemented via `self.fit(X, **fit_params).transform(X)`.  But it appears that `ColumnTransformer` is implemented in the opposite way: `fit` calls `self.fit_transform(X, y=y, **params)`.  Is there a reason for this?

This can cause a class that inherits from `ColumnTransformer` to display unintuitive behavior.  Suppose someone decides to override the `fit` method in a child class of `ColumnTransformer`.  If they call `fit_transform` on an object of that class, `fit_transform` will just ignore the user's new implementation of the `fit` method.

Additionally, perhaps this is a contrived example that will never actually be implemented in anyone's workflow, but this example class hits a `RecursionError` when fit:
```
class ColumnTransformer_Child(ColumnTransformer):

   def fit(self, X, y=None):
       return super().fit(X, y)
  
   def transform(self, X):
       return super().transform(X)
  
   def fit_transform(self, X, y=None):
       return self.fit(X).transform(X)
```

COMMENT:
There is a comment in the code:

```
# we use fit_transform to make sure to set sparse_output_ (for which we
# need the transformed data) to have consistent output type in predict
```

Labels: Needs Triage
C regularization parameter error when assigned infinity

### Describe the bug

I am trying to run a very simple SVC with the regularization parameter set to infinity, that is a hard-margin classifier.

### Steps/Code to Reproduce

```python
from sklearn.datasets import load_iris
from sklearn.svm import SVC

iris = load_iris()
w = np.where(iris["target"] < 2)
X = iris["data"][:, (2, 3)][w]
y = iris["target"][w]

svc = SVC(C=np.inf, kernel="linear")
svc.fit(X, y)
```

### Expected Results

The code runs without crashing.

### Actual Results

I obtain the following error message: `InvalidParameterError: The 'C' parameter of SVC must be a float in the range (0.0, inf). Got inf instead.`

### Versions

```shell
System:
    python: 3.12.3 (main, Jul 31 2024, 17:43:48) [GCC 13.2.0]
executable: /usr/bin/python3
   machine: Linux-6.8.0-41-generic-x86_64-with-glibc2.39

Python dependencies:
      sklearn: 1.4.1.post1
          pip: None
   setuptools: 68.1.2
        numpy: 1.26.4
        scipy: 1.11.4
       Cython: None
       pandas: 2.1.4+dfsg
   matplotlib: 3.6.3
       joblib: 1.3.2
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.26.so
        version: 0.3.26
threading_layer: pthreads
   architecture: Haswell
    num_threads: 20

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
        version: None
    num_threads: 20
```

COMMENT:
The parameter validation is catching this error so I would not be surprised this is a safeguard for not passing `inf` to `libsvm` that might have a non-define behaviour with this value.

Passing a really large number (e.g. `1e12`) should work similarly, isn't it?

Labels: Regression
C regularization parameter error when assigned infinity

### Describe the bug

I am trying to run a very simple SVC with the regularization parameter set to infinity, that is a hard-margin classifier.

### Steps/Code to Reproduce

```python
from sklearn.datasets import load_iris
from sklearn.svm import SVC

iris = load_iris()
w = np.where(iris["target"] < 2)
X = iris["data"][:, (2, 3)][w]
y = iris["target"][w]

svc = SVC(C=np.inf, kernel="linear")
svc.fit(X, y)
```

### Expected Results

The code runs without crashing.

### Actual Results

I obtain the following error message: `InvalidParameterError: The 'C' parameter of SVC must be a float in the range (0.0, inf). Got inf instead.`

### Versions

```shell
System:
    python: 3.12.3 (main, Jul 31 2024, 17:43:48) [GCC 13.2.0]
executable: /usr/bin/python3
   machine: Linux-6.8.0-41-generic-x86_64-with-glibc2.39

Python dependencies:
      sklearn: 1.4.1.post1
          pip: None
   setuptools: 68.1.2
        numpy: 1.26.4
        scipy: 1.11.4
       Cython: None
       pandas: 2.1.4+dfsg
   matplotlib: 3.6.3
       joblib: 1.3.2
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.26.so
        version: 0.3.26
threading_layer: pthreads
   architecture: Haswell
    num_threads: 20

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
        version: None
    num_threads: 20
```

COMMENT:
Thanks for the quick answer. In principle it should give close results with a very large values, though for a hard classifier, formally it should be +∞. However, I believe this is a regression as it worked in the past (I took that example from the book of Géron, and I do not remember having any issue with it back then). Looking at the git log, it may be before the bounds check was added. As an experiment, I locally edited https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/svm/_base.py#L88 to replace `"neither"` with `"right"`, and it appears to run correctly, giving the expected results. I do not have the machinery to run the tests, so I do not know whether it would break anything.

Labels: Regression
C regularization parameter error when assigned infinity

### Describe the bug

I am trying to run a very simple SVC with the regularization parameter set to infinity, that is a hard-margin classifier.

### Steps/Code to Reproduce

```python
from sklearn.datasets import load_iris
from sklearn.svm import SVC

iris = load_iris()
w = np.where(iris["target"] < 2)
X = iris["data"][:, (2, 3)][w]
y = iris["target"][w]

svc = SVC(C=np.inf, kernel="linear")
svc.fit(X, y)
```

### Expected Results

The code runs without crashing.

### Actual Results

I obtain the following error message: `InvalidParameterError: The 'C' parameter of SVC must be a float in the range (0.0, inf). Got inf instead.`

### Versions

```shell
System:
    python: 3.12.3 (main, Jul 31 2024, 17:43:48) [GCC 13.2.0]
executable: /usr/bin/python3
   machine: Linux-6.8.0-41-generic-x86_64-with-glibc2.39

Python dependencies:
      sklearn: 1.4.1.post1
          pip: None
   setuptools: 68.1.2
        numpy: 1.26.4
        scipy: 1.11.4
       Cython: None
       pandas: 2.1.4+dfsg
   matplotlib: 3.6.3
       joblib: 1.3.2
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.26.so
        version: 0.3.26
threading_layer: pthreads
   architecture: Haswell
    num_threads: 20

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
        version: None
    num_threads: 20
```

COMMENT:
> However, I believe this is a regression as it worked in the past (I took that example from the book of Géron, and I do not remember having any issue with it back then)

OK, this is a pretty good indicator then. We can change the bound and then it means that we should add a non-regression test because it was not tested :).

Probably the example of Aurélien Géron might be a good test :). The regression can be seen from: https://github.com/ageron/handson-ml/blob/master/05_support_vector_machines.ipynb to https://github.com/ageron/handson-ml3/blob/main/05_support_vector_machines.ipynb where `C` changed from `float(inf)` to `1e100` :).

Labels: Regression
⚠️ CI failed on Wheel builder (last failure: Aug 31, 2024) ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/10642170515)** (Aug 31, 2024)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/10650754762) on Sep 01, 2024

Labels: Needs Triage
Expose Seed in FeatureHasher and HashingVectorizer

### Describe the workflow you want to enable

Varying the seed of the FeatureHasher allows the user to control what inputs collide. This can allow for a better feature space either through experimentation (as a hyperparameter) or explicitly searching for a space that minimizes "bad" collisions

### Describe your proposed solution

Add an optional "seed" parameter to the init of [FeatureHasher](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/_hash.py#L20) which defaults to 0 (the current behavior, see [the underlying hashing function](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/_hashing_fast.pyx#L16)). The seed would be thread through to [_hashing_transform](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/_hash.py#L179)

Ditto for [HashingVectorizer](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/text.py#L903). Only difference here is that the seed would be passed to the [FeatureHasher instance](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/text.py#L903)

This seems straightforward so I can implement this solution if it makes sense

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

_No response_

### Additional context

_No response_

COMMENT:
I think that there is a lot of discussion in https://github.com/scikit-learn/scikit-learn/pull/14605 that makes this change at least controversial. I would need to read the entire discussion again to make sure what was the issue raised against adding a random state or seed to the `__init__`.

Labels: New Feature, Needs Decision
Expose Seed in FeatureHasher and HashingVectorizer

### Describe the workflow you want to enable

Varying the seed of the FeatureHasher allows the user to control what inputs collide. This can allow for a better feature space either through experimentation (as a hyperparameter) or explicitly searching for a space that minimizes "bad" collisions

### Describe your proposed solution

Add an optional "seed" parameter to the init of [FeatureHasher](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/_hash.py#L20) which defaults to 0 (the current behavior, see [the underlying hashing function](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/_hashing_fast.pyx#L16)). The seed would be thread through to [_hashing_transform](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/_hash.py#L179)

Ditto for [HashingVectorizer](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/text.py#L903). Only difference here is that the seed would be passed to the [FeatureHasher instance](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/feature_extraction/text.py#L903)

This seems straightforward so I can implement this solution if it makes sense

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

_No response_

### Additional context

_No response_

COMMENT:
What confuses me is that AFAICT those changes were merged and then reverted within 3 weeks without discussion.

Looking at the file's [commit history](https://github.com/scikit-learn/scikit-learn/commits/13134a884b92f8c601162ce4f125c2fc17c6ed4a/sklearn/feature_extraction/_hashing.py?browsing_rename_history=true&new_path=sklearn/feature_extraction/_hash.py&original_branch=main) the seed gets merged [here](https://github.com/scikit-learn/scikit-learn/commit/9b045d4bde6f8bd50d05468aad8731547ec21910), but removed the [next commit during a renaming](https://github.com/scikit-learn/scikit-learn/commit/bb3b3f9261bd092ed010d80de35fe031123c1687)

What's odd is that the seed variable doesn't even appear during the renaming, it looks like an old file was used. **Maybe I missed or misunderstood something, but  is it possible removing the seed was accidental? If so, could the seed be added back like was done by #14605?**

In the PR's discussion people seemed happy with the solution settled upon (variable called `seed` in `transform` that defaults to 0) and it would work for me

Labels: New Feature, Needs Decision