Talip7/scikit-learn-issues-multilabel huggingface dataset:
Add option gamma='scale' and 'auto' to RBFSampler

### Describe the workflow you want to enable

 Right now SVM supports gamma parameter to be set to 'scale' or 'auto', which will automatically determine gamma parameter based on data, but RBFSampler does not support this.

On top of that there is no check on n_components parameter, which allow users to set it to 0 and fit it without errors. It will only raise error if n_components is negative - `ValueError: negative dimensions are not allowed` (this is numpy error from random.normal generation, not sklearn one).

### Describe your proposed solution

Add 'scale' and 'auto' option to RBFSampler

### Describe alternatives you've considered, if relevant

It is possible to calculate gamma beforehand on your own, but it become increasingly tiresome if for example someone is performing CV - you will have to use custom loop instead of `cross_val_score` and others.

### Additional context

_No response_

COMMENT:
> On top of that there is no check on n_components parameter, which allow users to set it to 0 and fit it without errors. It will only raise error if n_components is negative - ValueError: negative dimensions are not allowed (this is numpy error from random.normal generation, not sklearn one).

This should not be the case in `main` since we introduce the parameter constraints:

https://github.com/scikit-learn/scikit-learn/blob/55b55afb2b6a8d1cc1d69ba1de0b4a370fa34c3a/sklearn/kernel_approximation.py#L321-L325

Regarding the proposal of adding the `str` option, I think that it could be nice to have the `"scale"` option. I don't know if the option `"auto"` is actually a good idea. Reading the change of default in the past (https://github.com/scikit-learn/scikit-learn/issues/8361), we would have probably not introduced it at first.

Labels: New Feature
Add option gamma='scale' and 'auto' to RBFSampler

### Describe the workflow you want to enable

 Right now SVM supports gamma parameter to be set to 'scale' or 'auto', which will automatically determine gamma parameter based on data, but RBFSampler does not support this.

On top of that there is no check on n_components parameter, which allow users to set it to 0 and fit it without errors. It will only raise error if n_components is negative - `ValueError: negative dimensions are not allowed` (this is numpy error from random.normal generation, not sklearn one).

### Describe your proposed solution

Add 'scale' and 'auto' option to RBFSampler

### Describe alternatives you've considered, if relevant

It is possible to calculate gamma beforehand on your own, but it become increasingly tiresome if for example someone is performing CV - you will have to use custom loop instead of `cross_val_score` and others.

### Additional context

_No response_

COMMENT:
If Needs Triage tag is removed, it's free to draft a PR?

Labels: New Feature
Add option gamma='scale' and 'auto' to RBFSampler

### Describe the workflow you want to enable

 Right now SVM supports gamma parameter to be set to 'scale' or 'auto', which will automatically determine gamma parameter based on data, but RBFSampler does not support this.

On top of that there is no check on n_components parameter, which allow users to set it to 0 and fit it without errors. It will only raise error if n_components is negative - `ValueError: negative dimensions are not allowed` (this is numpy error from random.normal generation, not sklearn one).

### Describe your proposed solution

Add 'scale' and 'auto' option to RBFSampler

### Describe alternatives you've considered, if relevant

It is possible to calculate gamma beforehand on your own, but it become increasingly tiresome if for example someone is performing CV - you will have to use custom loop instead of `cross_val_score` and others.

### Additional context

_No response_

COMMENT:
> If Needs Triage tag is removed, it's free to draft a PR?

Yep. We would still need to have another reviewer to review the PR but otherwise it should be fine.

Labels: New Feature
[RFC] Always convert lists of lists of numbers to numpy arrays during input validation.

### Describe the workflow you want to enable

Transformers and Estimators accept list of lists of numbers as valid for inputs like `X`.

Yet, when it comes to access to some basic attributes of the datasets (like the shape and the dtype which are present for numpy array) or to reach the best performances (e.g. be able to use Cython implementation which only operates on continuous buffers of memory), list of lists of numbers structure is inconvenient.

Also lists of lists really are used for simple examples (such as doctests) but are unlikely used in practice.

### Describe your proposed solution

I propose changing inputs validation to always convert list of list of numbers to their associated natural numpy array.

In this context:
 - lists of lists of Python `int` will be converted to 2D numpy array of `np.int64`
 - lists of lists of Python `float` will be converted to 2D numpy array of `np.float64`
 - a `RuntimeError` will be raised if leaf element aren't numbers
 - a `RuntimeError` will be raised if internals list have different length (the case of ragged array)

There might be some cost and maintenance complexity in converting list of lists to numpy array.

Changes mostly need be made in:

 - `BaseEstimator._validate_data`:
    https://github.com/scikit-learn/scikit-learn/blob/1dc23d7a1a798151a45ce1d72954821d61728411/sklearn/base.py#L453-L460
 
 - `sklearn.utils.check_array`:
   https://github.com/scikit-learn/scikit-learn/blob/7b0a16206558b0297a7f38a5a17fe06970a45894/sklearn/utils/validation.py#L629-L644

### Describe alternatives you've considered, if relevant

Continue supporting list of lists of numbers and introduce utility functions to be able to get basic attributes of the datasets which this structure.

### Additional context

Listing references as I find them:
 - [`43a61c4` (#22665)](https://github.com/scikit-learn/scikit-learn/pull/22665/commits/43a61c48c14192f99dfb5c49460d745c5377e0a5)
 - https://github.com/scikit-learn/scikit-learn/pull/23958/files#r1003462690

COMMENT:
As far as I know, we would always convert a list of lists to a NumPy array. I can think of 2 cases that this is not the case:

- Some meta-estimators where we validate using `_num_samples` and `_num_features`. From the top of the head it was to avoid multiple validations.
- Vectorizer for text will keep a list of str as input.

What I am missing here is the context where an estimator will actually be using these lists of lists in the internal algorithm?

Labels: New Feature, RFC, frontend, Validation
[RFC] Always convert lists of lists of numbers to numpy arrays during input validation.

### Describe the workflow you want to enable

Transformers and Estimators accept list of lists of numbers as valid for inputs like `X`.

Yet, when it comes to access to some basic attributes of the datasets (like the shape and the dtype which are present for numpy array) or to reach the best performances (e.g. be able to use Cython implementation which only operates on continuous buffers of memory), list of lists of numbers structure is inconvenient.

Also lists of lists really are used for simple examples (such as doctests) but are unlikely used in practice.

### Describe your proposed solution

I propose changing inputs validation to always convert list of list of numbers to their associated natural numpy array.

In this context:
 - lists of lists of Python `int` will be converted to 2D numpy array of `np.int64`
 - lists of lists of Python `float` will be converted to 2D numpy array of `np.float64`
 - a `RuntimeError` will be raised if leaf element aren't numbers
 - a `RuntimeError` will be raised if internals list have different length (the case of ragged array)

There might be some cost and maintenance complexity in converting list of lists to numpy array.

Changes mostly need be made in:

 - `BaseEstimator._validate_data`:
    https://github.com/scikit-learn/scikit-learn/blob/1dc23d7a1a798151a45ce1d72954821d61728411/sklearn/base.py#L453-L460
 
 - `sklearn.utils.check_array`:
   https://github.com/scikit-learn/scikit-learn/blob/7b0a16206558b0297a7f38a5a17fe06970a45894/sklearn/utils/validation.py#L629-L644

### Describe alternatives you've considered, if relevant

Continue supporting list of lists of numbers and introduce utility functions to be able to get basic attributes of the datasets which this structure.

### Additional context

Listing references as I find them:
 - [`43a61c4` (#22665)](https://github.com/scikit-learn/scikit-learn/pull/22665/commits/43a61c48c14192f99dfb5c49460d745c5377e0a5)
 - https://github.com/scikit-learn/scikit-learn/pull/23958/files#r1003462690

COMMENT:
> What I am missing here is the context where an estimator will actually be using these lists of lists in the internal algorithm?

I am attaching a few pointers to the description of this PR.

Labels: New Feature, RFC, frontend, Validation
[RFC] Always convert lists of lists of numbers to numpy arrays during input validation.

### Describe the workflow you want to enable

Transformers and Estimators accept list of lists of numbers as valid for inputs like `X`.

Yet, when it comes to access to some basic attributes of the datasets (like the shape and the dtype which are present for numpy array) or to reach the best performances (e.g. be able to use Cython implementation which only operates on continuous buffers of memory), list of lists of numbers structure is inconvenient.

Also lists of lists really are used for simple examples (such as doctests) but are unlikely used in practice.

### Describe your proposed solution

I propose changing inputs validation to always convert list of list of numbers to their associated natural numpy array.

In this context:
 - lists of lists of Python `int` will be converted to 2D numpy array of `np.int64`
 - lists of lists of Python `float` will be converted to 2D numpy array of `np.float64`
 - a `RuntimeError` will be raised if leaf element aren't numbers
 - a `RuntimeError` will be raised if internals list have different length (the case of ragged array)

There might be some cost and maintenance complexity in converting list of lists to numpy array.

Changes mostly need be made in:

 - `BaseEstimator._validate_data`:
    https://github.com/scikit-learn/scikit-learn/blob/1dc23d7a1a798151a45ce1d72954821d61728411/sklearn/base.py#L453-L460
 
 - `sklearn.utils.check_array`:
   https://github.com/scikit-learn/scikit-learn/blob/7b0a16206558b0297a7f38a5a17fe06970a45894/sklearn/utils/validation.py#L629-L644

### Describe alternatives you've considered, if relevant

Continue supporting list of lists of numbers and introduce utility functions to be able to get basic attributes of the datasets which this structure.

### Additional context

Listing references as I find them:
 - [`43a61c4` (#22665)](https://github.com/scikit-learn/scikit-learn/pull/22665/commits/43a61c48c14192f99dfb5c49460d745c5377e0a5)
 - https://github.com/scikit-learn/scikit-learn/pull/23958/files#r1003462690

COMMENT:
Typically [`43a61c4` (#22665)](https://github.com/scikit-learn/scikit-learn/pull/22665/commits/43a61c48c14192f99dfb5c49460d745c5377e0a5) is such an example where we delay the validation in `_fit` because it is shared between estimator.

So we certainly want to avoid validating the data twice. Maybe the workaround here is to store the `self._X_dtype` in `_fit` such that we can reuse it `_fit`.

Labels: New Feature, RFC, frontend, Validation
[RFC] Always convert lists of lists of numbers to numpy arrays during input validation.

### Describe the workflow you want to enable

Transformers and Estimators accept list of lists of numbers as valid for inputs like `X`.

Yet, when it comes to access to some basic attributes of the datasets (like the shape and the dtype which are present for numpy array) or to reach the best performances (e.g. be able to use Cython implementation which only operates on continuous buffers of memory), list of lists of numbers structure is inconvenient.

Also lists of lists really are used for simple examples (such as doctests) but are unlikely used in practice.

### Describe your proposed solution

I propose changing inputs validation to always convert list of list of numbers to their associated natural numpy array.

In this context:
 - lists of lists of Python `int` will be converted to 2D numpy array of `np.int64`
 - lists of lists of Python `float` will be converted to 2D numpy array of `np.float64`
 - a `RuntimeError` will be raised if leaf element aren't numbers
 - a `RuntimeError` will be raised if internals list have different length (the case of ragged array)

There might be some cost and maintenance complexity in converting list of lists to numpy array.

Changes mostly need be made in:

 - `BaseEstimator._validate_data`:
    https://github.com/scikit-learn/scikit-learn/blob/1dc23d7a1a798151a45ce1d72954821d61728411/sklearn/base.py#L453-L460
 
 - `sklearn.utils.check_array`:
   https://github.com/scikit-learn/scikit-learn/blob/7b0a16206558b0297a7f38a5a17fe06970a45894/sklearn/utils/validation.py#L629-L644

### Describe alternatives you've considered, if relevant

Continue supporting list of lists of numbers and introduce utility functions to be able to get basic attributes of the datasets which this structure.

### Additional context

Listing references as I find them:
 - [`43a61c4` (#22665)](https://github.com/scikit-learn/scikit-learn/pull/22665/commits/43a61c48c14192f99dfb5c49460d745c5377e0a5)
 - https://github.com/scikit-learn/scikit-learn/pull/23958/files#r1003462690

COMMENT:
> lists of lists of Python int will be converted to 2D numpy array of np.int64
lists of lists of Python float will be converted to 2D numpy array of np.float64

This is already what `check_array` does. I'm not sure to understand what you would change. As @glemaitre pointed out, there are specific cases where we don't want to call check_array early to avoid repeating the validation several times (in meta-estimators essentially)

Labels: New Feature, RFC, frontend, Validation
[RFC] Always convert lists of lists of numbers to numpy arrays during input validation.

### Describe the workflow you want to enable

Transformers and Estimators accept list of lists of numbers as valid for inputs like `X`.

Yet, when it comes to access to some basic attributes of the datasets (like the shape and the dtype which are present for numpy array) or to reach the best performances (e.g. be able to use Cython implementation which only operates on continuous buffers of memory), list of lists of numbers structure is inconvenient.

Also lists of lists really are used for simple examples (such as doctests) but are unlikely used in practice.

### Describe your proposed solution

I propose changing inputs validation to always convert list of list of numbers to their associated natural numpy array.

In this context:
 - lists of lists of Python `int` will be converted to 2D numpy array of `np.int64`
 - lists of lists of Python `float` will be converted to 2D numpy array of `np.float64`
 - a `RuntimeError` will be raised if leaf element aren't numbers
 - a `RuntimeError` will be raised if internals list have different length (the case of ragged array)

There might be some cost and maintenance complexity in converting list of lists to numpy array.

Changes mostly need be made in:

 - `BaseEstimator._validate_data`:
    https://github.com/scikit-learn/scikit-learn/blob/1dc23d7a1a798151a45ce1d72954821d61728411/sklearn/base.py#L453-L460
 
 - `sklearn.utils.check_array`:
   https://github.com/scikit-learn/scikit-learn/blob/7b0a16206558b0297a7f38a5a17fe06970a45894/sklearn/utils/validation.py#L629-L644

### Describe alternatives you've considered, if relevant

Continue supporting list of lists of numbers and introduce utility functions to be able to get basic attributes of the datasets which this structure.

### Additional context

Listing references as I find them:
 - [`43a61c4` (#22665)](https://github.com/scikit-learn/scikit-learn/pull/22665/commits/43a61c48c14192f99dfb5c49460d745c5377e0a5)
 - https://github.com/scikit-learn/scikit-learn/pull/23958/files#r1003462690

COMMENT:
Ah yes, I missed that. I have been able to find my way around and I was not informed when I wrote this RFC. Hence let's close it.

Labels: New Feature, RFC, frontend, Validation
Mandatory random seeds

### Describe the workflow you want to enable

So far, in methods such as `train_test_split`, it is not mandatory to set a random seed. In the default case, where the seed is `None`, the seed is determined randomly.

Thus, I would like to propose making mandatory setting the random seeds of **all** algorithms, classes and methods that request one.

### Describe your proposed solution

My idea for solving this issue is simple: raising an error if a seed was not set as a parameter for a given algorithm/method/class.

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

Alternatively, if this could not be implemented, I would propose giving a warning to the user if a seed was not set.

### Additional context

Given all the problems regarding reproducibility in data science and machine learning, I think a good first step in tackling this problem is to make aware to as many developers as possible of the importance of having reproducible results.

And to get reproducible results, it should be mandatory to **always** use non-default random seeds in the code since, in this way, the same seeds will yield the same results, thus achieving fully reproducible results.

COMMENT:
I know there are arguments for not having a seed in a script as well. I don't think we'll be making it mandatory, we could talk about a warning, but still support a no-random seed and no warning case.

It's true that I've seen a lot of issues/questions where the answer has been: you forgot to set the seed for that particular object/method.

Tagging @scikit-learn/core-devs here.

Labels: RFC
Mandatory random seeds

### Describe the workflow you want to enable

So far, in methods such as `train_test_split`, it is not mandatory to set a random seed. In the default case, where the seed is `None`, the seed is determined randomly.

Thus, I would like to propose making mandatory setting the random seeds of **all** algorithms, classes and methods that request one.

### Describe your proposed solution

My idea for solving this issue is simple: raising an error if a seed was not set as a parameter for a given algorithm/method/class.

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

Alternatively, if this could not be implemented, I would propose giving a warning to the user if a seed was not set.

### Additional context

Given all the problems regarding reproducibility in data science and machine learning, I think a good first step in tackling this problem is to make aware to as many developers as possible of the importance of having reproducible results.

And to get reproducible results, it should be mandatory to **always** use non-default random seeds in the code since, in this way, the same seeds will yield the same results, thus achieving fully reproducible results.

COMMENT:
Always fixing the seeds might give a misleading sense of determinism, this is why we intentionally decided to not hide the inherent randomness of a scikit-learn algorithms at the beginning of the scikit-learn project (12 years ago).

Since setting `random_state=None` means using the `numpy.random` singleton, it's possible to seed all the scikit-learn algorithms in a given Python program by calling `numpy.random.seed(some_integer_seed)` at the beginning.

Labels: RFC
Mandatory random seeds

### Describe the workflow you want to enable

So far, in methods such as `train_test_split`, it is not mandatory to set a random seed. In the default case, where the seed is `None`, the seed is determined randomly.

Thus, I would like to propose making mandatory setting the random seeds of **all** algorithms, classes and methods that request one.

### Describe your proposed solution

My idea for solving this issue is simple: raising an error if a seed was not set as a parameter for a given algorithm/method/class.

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

Alternatively, if this could not be implemented, I would propose giving a warning to the user if a seed was not set.

### Additional context

Given all the problems regarding reproducibility in data science and machine learning, I think a good first step in tackling this problem is to make aware to as many developers as possible of the importance of having reproducible results.

And to get reproducible results, it should be mandatory to **always** use non-default random seeds in the code since, in this way, the same seeds will yield the same results, thus achieving fully reproducible results.

COMMENT:
Maybe we could introduce a new random variable `SKLEARN_DEFAULT_RANDOM_STATE_SEED` and use that whenever `check_random_state(None)` is called. This way that would make it possible to make a scikit-learn program deterministic and reproducible without having to edit the source code (assuming there is no other source of non-determinism in the program).

Maybe this could actually discuss implementing this upstream in numpy itself.

Labels: RFC
Mandatory random seeds

### Describe the workflow you want to enable

So far, in methods such as `train_test_split`, it is not mandatory to set a random seed. In the default case, where the seed is `None`, the seed is determined randomly.

Thus, I would like to propose making mandatory setting the random seeds of **all** algorithms, classes and methods that request one.

### Describe your proposed solution

My idea for solving this issue is simple: raising an error if a seed was not set as a parameter for a given algorithm/method/class.

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

Alternatively, if this could not be implemented, I would propose giving a warning to the user if a seed was not set.

### Additional context

Given all the problems regarding reproducibility in data science and machine learning, I think a good first step in tackling this problem is to make aware to as many developers as possible of the importance of having reproducible results.

And to get reproducible results, it should be mandatory to **always** use non-default random seeds in the code since, in this way, the same seeds will yield the same results, thus achieving fully reproducible results.

COMMENT:
> Always fixing the seeds might give a misleading sense of determinism

I am really scared about this. My second fear is about optimizing the outcome of the ML pipeline. Forcing the seeding of algorithms might conduct the search for the best integer that leads to the best ML pipeline. I agree that advanced users are aware that the `random_state` will be used for reproducibility and not metric optimization but it brings the trap closer to beginners.

Labels: RFC