Talip7/scikit-learn-issues-multilabel huggingface dataset:
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
@eric-wieser @seberg friendly ping. We would like to better understand the numpy recommendation of using `np.asarray(x).nonzero()` over `np.where(x)`.

Personally, I would follow numpy‘s recommendation without questioning it too much: their realm, their expertise.

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
`where` skips the `.nonzero()` attribute, so if a subclass defines that it is different (maybe only then).  Of course these days the subclass could define `__array_wrap__` so it is less of a thing maybe.
I never loved the overload of `where` to have two meanings, although I bet "where" sounds nicer to many than `nonzero`.

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
Related PR: #30519

I will add a good-first-issue label to this one.

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
Hey, I would like to take care of this one. For clarification, we would want to look through the examples and where we're using `np.where(condition),` change the code to `np.asarray(condition).nonzero()` instead?

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
> Hey, I would like to take care of this one. For clarification, we would want to look through the examples and where we're using np.where(condition), change the code to np.asarray(condition).nonzero() instead?

Hello @JoaoRodriguesIST, yes, and be aware the condition might already be a numpy array and in this case you don't need to convert it first.

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
Hello, is the issue still? I can fix it. /take

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
@JoaoRodriguesIST has already taken this.

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
Ok, thanks! I will work on it this following week.

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
Should be opening a PR on this soon.

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
Hello all,

@StefanieSenger, @JoaoRodriguesIST Is this Issue still open?

I noticed that 13 of the `examples/` were already adjusted in the PR #31115.

Also, I found that `np.where` is being used 82 times in 52 files that are not in the `example/` folder, and some of them are exactly the situation where `np.where(condition)` is used [example](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/multiclass.py#L512).

For files that are not in the `examples/` folder, should this modification also be done?

Labels: good first issue
Finding indexes with `np.where(condition)` or `np.asarray(condition).nonzero()`

Throughout the repo, we use `np.where(condition)` for getting indexes, for instance in [SelectorMixin.get_support()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/feature_selection/_base.py#L73), in [SimpleImputer.transform()](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/impute/_base.py#L670) and in several of our examples ([example](https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/examples/linear_model/plot_sgd_iris.py#L58)).

The numpy documentation [discourages](https://numpy.org/doc/2.1/reference/generated/numpy.where.html) the use of `np.where` with just passing a condition and recommends `np.asarray(condition).nonzero()` instead.

For cleanliness of code, should we adopt this recommendation, at least in the examples? Or are there good reasons why we do that?

COMMENT:
> Also, I found that np.where is being used 82 times in 52 files that are not in the example/ folder, and some of them are exactly the situation where np.where(condition) is used [example](https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/multiclass.py#L512).

Yes, we had discussed this, but there was no consensus in changing these too.

I will close this issue.

Labels: good first issue
New example about how to implement the SuperLearner in Python

### Describe the issue linked to the documentation

The SuperLearner is a stacking strategy that is very used in fields like Statistics (for instance in causal inference, survival analysis etc) to obtain a good machine learning model fitted to your data without caring too much about model selection. It is implemented as [an R package](https://cran.r-project.org/web/packages/SuperLearner/index.html) with a [good documentation](https://cran.r-project.org/web/packages/SuperLearner/vignettes/Guide-to-SuperLearner.html), but not available off-the-shelf in Python, while it is not very difficult to do with Scikit-Learn

### Suggest a potential alternative/fix

Probably not in the spirit of Scikit-Learn to implement it, but a good example explaining briefly what it is, and how to do it in a nice way in Scikit-Learn could be super helpful!

happy to help (either write, review etc) if needed

COMMENT:
The main paper was published in 2010 and was cited more than 400 times so would meet our inclusion criteria.

https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Super+Learner+In+Prediction&btnG=

The algorithm is presented in section 2 of [the paper](https://biostats.bepress.com/cgi/viewcontent.cgi?article=1269&context=ucbbiostat):

![image](https://github.com/user-attachments/assets/16b6ec06-373e-4e0f-a476-227e7c83a6ab)

It seems very close to our StackingClassifier/Regressor model where the second stage model is a Ridge classifier or regressor model with positivity constraints on the coefficients (and an extra constraint that they should sum to one):

https://scikit-learn.org/stable/modules/ensemble.html#stacked-generalization

The main difference with what we currently have in scikit-learn is the preconfigured list of base estimators used to populate the first stage.

Things that we could explore:

- improve the existing usage example of stacking in scikit-learn to provide a better list of base models (e.g. mixing MLPs, tree-based models and linear models with non-linear feature engineering, e.g. splines and/or kernel approximators) and illustrate this on a more realistic dataset with a mix of categorical and numerical features;
- consider providing a preconfigured list of base estimators/pipelines as part of the libraries itself;
- maybe create a `superlearner` package under [scikit-learn-contrib](https://github.com/scikit-learn-contrib) that tries to mimic the default config and high-level features of the R package?

Our only example is:
https://scikit-learn.org/stable/auto_examples/ensemble/plot_stack_predictors.html

Labels: Documentation, Needs Decision - Include Feature
New example about how to implement the SuperLearner in Python

### Describe the issue linked to the documentation

The SuperLearner is a stacking strategy that is very used in fields like Statistics (for instance in causal inference, survival analysis etc) to obtain a good machine learning model fitted to your data without caring too much about model selection. It is implemented as [an R package](https://cran.r-project.org/web/packages/SuperLearner/index.html) with a [good documentation](https://cran.r-project.org/web/packages/SuperLearner/vignettes/Guide-to-SuperLearner.html), but not available off-the-shelf in Python, while it is not very difficult to do with Scikit-Learn

### Suggest a potential alternative/fix

Probably not in the spirit of Scikit-Learn to implement it, but a good example explaining briefly what it is, and how to do it in a nice way in Scikit-Learn could be super helpful!

happy to help (either write, review etc) if needed

COMMENT:
Totally agreed that it is not to be implemented in Scikit-Learn. The idea would be to include it in the documentation through an example, either in the existing stacking example or through a new example. With an explicit mention of the SuperLearner paper and/or package in the example? (so that it is findable when looking for "super learner python" on your favorite search engine), wdyt?

your other suggestions are really interesting too, maybe in a second step if needed? depending on the reach of use of the example base code (not sure how to measure it directly, but communication metrics can help)

Labels: Documentation, Needs Decision - Include Feature
New example about how to implement the SuperLearner in Python

### Describe the issue linked to the documentation

The SuperLearner is a stacking strategy that is very used in fields like Statistics (for instance in causal inference, survival analysis etc) to obtain a good machine learning model fitted to your data without caring too much about model selection. It is implemented as [an R package](https://cran.r-project.org/web/packages/SuperLearner/index.html) with a [good documentation](https://cran.r-project.org/web/packages/SuperLearner/vignettes/Guide-to-SuperLearner.html), but not available off-the-shelf in Python, while it is not very difficult to do with Scikit-Learn

### Suggest a potential alternative/fix

Probably not in the spirit of Scikit-Learn to implement it, but a good example explaining briefly what it is, and how to do it in a nice way in Scikit-Learn could be super helpful!

happy to help (either write, review etc) if needed

COMMENT:
Providing a list of good based linear pipelines might also be useful for #6329 (greedy ensemble) which is very related.

Labels: Documentation, Needs Decision - Include Feature
New example about how to implement the SuperLearner in Python

### Describe the issue linked to the documentation

The SuperLearner is a stacking strategy that is very used in fields like Statistics (for instance in causal inference, survival analysis etc) to obtain a good machine learning model fitted to your data without caring too much about model selection. It is implemented as [an R package](https://cran.r-project.org/web/packages/SuperLearner/index.html) with a [good documentation](https://cran.r-project.org/web/packages/SuperLearner/vignettes/Guide-to-SuperLearner.html), but not available off-the-shelf in Python, while it is not very difficult to do with Scikit-Learn

### Suggest a potential alternative/fix

Probably not in the spirit of Scikit-Learn to implement it, but a good example explaining briefly what it is, and how to do it in a nice way in Scikit-Learn could be super helpful!

happy to help (either write, review etc) if needed

COMMENT:
I also agree that mentionning "SuperLearner" either in the docstring of the stacking meta-estimators, or in the user guide or in the example or in all of the above might be helpful for googleability.

Labels: Documentation, Needs Decision - Include Feature
New example about how to implement the SuperLearner in Python

### Describe the issue linked to the documentation

The SuperLearner is a stacking strategy that is very used in fields like Statistics (for instance in causal inference, survival analysis etc) to obtain a good machine learning model fitted to your data without caring too much about model selection. It is implemented as [an R package](https://cran.r-project.org/web/packages/SuperLearner/index.html) with a [good documentation](https://cran.r-project.org/web/packages/SuperLearner/vignettes/Guide-to-SuperLearner.html), but not available off-the-shelf in Python, while it is not very difficult to do with Scikit-Learn

### Suggest a potential alternative/fix

Probably not in the spirit of Scikit-Learn to implement it, but a good example explaining briefly what it is, and how to do it in a nice way in Scikit-Learn could be super helpful!

happy to help (either write, review etc) if needed

COMMENT:
I think it's what pymc is calling [`WeightedProportion`](https://causalpy.readthedocs.io/en/stable/api/generated/causalpy.skl_models.WeightedProportion.html) or [`WeightedSumFitter`](https://causalpy.readthedocs.io/en/stable/api/generated/causalpy.pymc_models.WeightedSumFitter.html). It has nice properties in terms of regularization, interpretability and works better than `Ridge(positive=True)` on small datasets, but I don't think it is worth to be added, since it is easy to implement on your own and it's not a universal estimator by any means.
Maybe it could fit into `VotingClassifier` / `VotingRegressor` for example as `weights='auto'`?

Labels: Documentation, Needs Decision - Include Feature
ENH Allow disabling refitting of cross-validation estimators

### Discussed in https://github.com/scikit-learn/scikit-learn/discussions/30233

<div type='discussions-op-text'>

<sup>Originally posted by **AhmedThahir** November  7, 2024</sup>
Feature request: Allow disable refitting of cross-validation estimators (such as LassoCV, RidgeCV) on the full training set after finding the best hyperparameters?

Sometimes I only want the optimal hyperparameter and do not want to waste resources on refitting. This is especially important for large datasets. </div>

As @alifa98 has highlighted, this is the relevant code block.
https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/linear_model/_coordinate_descent.py#L1815

User should be allowed to toggle this behavior.

COMMENT:
That's great idea as many people will be trying so that they can prevent from refitting itself on full training set, I am working on this.

Labels: Enhancement
ENH Allow disabling refitting of cross-validation estimators

### Discussed in https://github.com/scikit-learn/scikit-learn/discussions/30233

<div type='discussions-op-text'>

<sup>Originally posted by **AhmedThahir** November  7, 2024</sup>
Feature request: Allow disable refitting of cross-validation estimators (such as LassoCV, RidgeCV) on the full training set after finding the best hyperparameters?

Sometimes I only want the optimal hyperparameter and do not want to waste resources on refitting. This is especially important for large datasets. </div>

As @alifa98 has highlighted, this is the relevant code block.
https://github.com/scikit-learn/scikit-learn/blob/fba028b07ed2b4e52dd3719dad0d990837bde28c/sklearn/linear_model/_coordinate_descent.py#L1815

User should be allowed to toggle this behavior.

COMMENT:
Hi @AhmedThahir  and @PredictiveManish, I'm +1 to add this feature. It allows finding the best hyperparameter while benefiting from the better performance of these specialized estimators over GridSearchCV.

Labels: Enhancement