Talip7/scikit-learn-issues-multilabel huggingface dataset:
Rename `frozen.FrozenEstimator` to `frozen.Frozen`

Looking through all our estimators, none of them have the word "Estimator" besides `BaseEstimator` and `MetaEstimatorMixin`. I think we can shorten the meta-estimator name to `Frozen`.

CC @adrinjalali @scikit-learn/core-devs

COMMENT:
First reaction wise I like `Frozen` because it is nice and short. Having `Estimator` added on also feels "natural" because a lot of other classes say what they are `Classifier`, `Trasnformer`, .. in the class name. And this is something that works on all estimators, so it is one.

However, you can also argue that if it is an estimator then you don't really need to specify it because, well, "everything is an estimator". Also `Frozen(my_random_forest)` looks nice as code. But it also makes me think really it should be a function `frozen(my_rf)` - which we discussed in a different thread.

I am -1 on `Freezer` - IMHO it is too weird. "I'll be right back, just going to put my random forest in the freezer!"

Labels: API, Blocker, RFC
Rename `frozen.FrozenEstimator` to `frozen.Frozen`

Looking through all our estimators, none of them have the word "Estimator" besides `BaseEstimator` and `MetaEstimatorMixin`. I think we can shorten the meta-estimator name to `Frozen`.

CC @adrinjalali @scikit-learn/core-devs

COMMENT:
> Also Frozen(my_random_forest) looks nice as code. But it also makes me think really it should be a function frozen(my_rf) - which we discussed in a different thread.
> I am -1 on Freezer - IMHO it is too weird. "I'll be right back, just going to put my random forest in the freezer!"

Thinking loudly here.

This is indeed the initial reason why I like `Freezer`: it represents an object as opposed to `Frozen` that is more a functionality. And to be coherent, I'm also +1 to then have a `freeze` function/method that expose the functionality itself.

However, thinking of a potential `repr`: `Freezer(RandomForestClassifier())` is indeed weird compare to `Frozen(RandomForestClassifier())`. So I probably can be OK with a `freeze` functionality (function/method) that return you a `Frozen` estimator.

So still +0.5.

Labels: API, Blocker, RFC
Rename `frozen.FrozenEstimator` to `frozen.Frozen`

Looking through all our estimators, none of them have the word "Estimator" besides `BaseEstimator` and `MetaEstimatorMixin`. I think we can shorten the meta-estimator name to `Frozen`.

CC @adrinjalali @scikit-learn/core-devs

COMMENT:
I also prefer `Frozen(Estimator)` for the class name to `Freezer`: otherwise, using an instance of `Freezer` to transform or predict on some data would imply that it somehow freezes the data, which is not what it is actually doing.

The action of producing an instance of frozen estimator should instead be named `freeze` (be it a method or a function).

Labels: API, Blocker, RFC
Rename `frozen.FrozenEstimator` to `frozen.Frozen`

Looking through all our estimators, none of them have the word "Estimator" besides `BaseEstimator` and `MetaEstimatorMixin`. I think we can shorten the meta-estimator name to `Frozen`.

CC @adrinjalali @scikit-learn/core-devs

COMMENT:
https://github.com/scikit-learn/scikit-learn/pull/30209 for the rename then

Labels: API, Blocker, RFC
Rename `frozen.FrozenEstimator` to `frozen.Frozen`

Looking through all our estimators, none of them have the word "Estimator" besides `BaseEstimator` and `MetaEstimatorMixin`. I think we can shorten the meta-estimator name to `Frozen`.

CC @adrinjalali @scikit-learn/core-devs

COMMENT:
I'm okay with the current `FrozenEstimator` name. I do not want users to end up writing `Frozen(X_train)`, because `Frozen` is not explicit about what it expects as input.

(We kind of have the same issue with `clone`, but that is not really a user facing API)

Labels: API, Blocker, RFC
Rename `frozen.FrozenEstimator` to `frozen.Frozen`

Looking through all our estimators, none of them have the word "Estimator" besides `BaseEstimator` and `MetaEstimatorMixin`. I think we can shorten the meta-estimator name to `Frozen`.

CC @adrinjalali @scikit-learn/core-devs

COMMENT:
Ok then, I guess we're settled on `FrozenEstimator` then.

Labels: API, Blocker, RFC
Towncrier categories overlap

### Describe the issue linked to the documentation

I had first [commented](https://github.com/scikit-learn/scikit-learn/pull/30046#issuecomment-2451761128) this on an issue, but I think maybe it is worth its own issue:

These categories that are listed in the [changelog instructions](https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md):
```
    major-feature
    feature
    efficiency
    enhancement
    fix
    api
```
are overlapping and don't cover everything. 

We have used them since 2019, but now they play a much bigger role than ever. Before, we simply put [ENH] or [MNT] in front of the changelog entries, we were allowed to deviate from them if needed, and the changes were not sortable by these categories. Now they are much more prominent and we cannot use different ones (or at least the documentation suggests that we cannot).

Major concerns:
1. `api` will always be affected with `major-feature` and `feature` and maybe `enhancement`. It is ambiguous for us where to put these and possibly confusing to users.
2. There is not really a good place to put maintenance PRs and people would probably put them into `enhancement` (which it is not) and `fix` (which it is not).

### Suggest a potential alternative/fix

Discuss which (non-overlapping) categories are needed/wanted.

COMMENT:
Regarding the `api`, the definition that I think of it as explain by NumPy (https://numpy.org/doc/stable/dev/development_workflow.html#writing-the-commit-message): an incompatible API change. Deprecations are typically part of such category. Future change of default is also one. Making private functions to public functions is another case. So the important word here is "incompatible". I think that I'm fine to stick to this label until we define it properly.

Regarding the maintenance PR, I agree with you. We already merge some PR with the `MAINT` prefix so it could be a category. Sometimes we consider that those PRs do not land into the changelog because they don't impact directly our end-user. But if it should be the case, then we are in trouble as you explain. So having this new category would make sense to me.

Labels: Documentation
Towncrier categories overlap

### Describe the issue linked to the documentation

I had first [commented](https://github.com/scikit-learn/scikit-learn/pull/30046#issuecomment-2451761128) this on an issue, but I think maybe it is worth its own issue:

These categories that are listed in the [changelog instructions](https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md):
```
    major-feature
    feature
    efficiency
    enhancement
    fix
    api
```
are overlapping and don't cover everything. 

We have used them since 2019, but now they play a much bigger role than ever. Before, we simply put [ENH] or [MNT] in front of the changelog entries, we were allowed to deviate from them if needed, and the changes were not sortable by these categories. Now they are much more prominent and we cannot use different ones (or at least the documentation suggests that we cannot).

Major concerns:
1. `api` will always be affected with `major-feature` and `feature` and maybe `enhancement`. It is ambiguous for us where to put these and possibly confusing to users.
2. There is not really a good place to put maintenance PRs and people would probably put them into `enhancement` (which it is not) and `fix` (which it is not).

### Suggest a potential alternative/fix

Discuss which (non-overlapping) categories are needed/wanted.

COMMENT:
I don't recall a case where a maintenence PR required a changelog though, do we have them?

Regarding the overlap, I don't think it's a big deal. Almost nobody reads the changelog. and the categories are not really important IMO.

Labels: Documentation
Towncrier categories overlap

### Describe the issue linked to the documentation

I had first [commented](https://github.com/scikit-learn/scikit-learn/pull/30046#issuecomment-2451761128) this on an issue, but I think maybe it is worth its own issue:

These categories that are listed in the [changelog instructions](https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md):
```
    major-feature
    feature
    efficiency
    enhancement
    fix
    api
```
are overlapping and don't cover everything. 

We have used them since 2019, but now they play a much bigger role than ever. Before, we simply put [ENH] or [MNT] in front of the changelog entries, we were allowed to deviate from them if needed, and the changes were not sortable by these categories. Now they are much more prominent and we cannot use different ones (or at least the documentation suggests that we cannot).

Major concerns:
1. `api` will always be affected with `major-feature` and `feature` and maybe `enhancement`. It is ambiguous for us where to put these and possibly confusing to users.
2. There is not really a good place to put maintenance PRs and people would probably put them into `enhancement` (which it is not) and `fix` (which it is not).

### Suggest a potential alternative/fix

Discuss which (non-overlapping) categories are needed/wanted.

COMMENT:
Wonder what @lesteve thinks here.

Labels: Documentation
Towncrier categories overlap

### Describe the issue linked to the documentation

I had first [commented](https://github.com/scikit-learn/scikit-learn/pull/30046#issuecomment-2451761128) this on an issue, but I think maybe it is worth its own issue:

These categories that are listed in the [changelog instructions](https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md):
```
    major-feature
    feature
    efficiency
    enhancement
    fix
    api
```
are overlapping and don't cover everything. 

We have used them since 2019, but now they play a much bigger role than ever. Before, we simply put [ENH] or [MNT] in front of the changelog entries, we were allowed to deviate from them if needed, and the changes were not sortable by these categories. Now they are much more prominent and we cannot use different ones (or at least the documentation suggests that we cannot).

Major concerns:
1. `api` will always be affected with `major-feature` and `feature` and maybe `enhancement`. It is ambiguous for us where to put these and possibly confusing to users.
2. There is not really a good place to put maintenance PRs and people would probably put them into `enhancement` (which it is not) and `fix` (which it is not).

### Suggest a potential alternative/fix

Discuss which (non-overlapping) categories are needed/wanted.

COMMENT:
> I don't recall a case where a maintenence PR required a changelog though, do we have them?

Hm, I was thinking so. I was stumbling over this problem reviewing PR #30152. In general, deprecation PRs or changing error messages could be seen as MNT. I don't find it easy to see them as an enhancement or fix, because we're neither adding nor reparing anything.

Labels: Documentation
Towncrier categories overlap

### Describe the issue linked to the documentation

I had first [commented](https://github.com/scikit-learn/scikit-learn/pull/30046#issuecomment-2451761128) this on an issue, but I think maybe it is worth its own issue:

These categories that are listed in the [changelog instructions](https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md):
```
    major-feature
    feature
    efficiency
    enhancement
    fix
    api
```
are overlapping and don't cover everything. 

We have used them since 2019, but now they play a much bigger role than ever. Before, we simply put [ENH] or [MNT] in front of the changelog entries, we were allowed to deviate from them if needed, and the changes were not sortable by these categories. Now they are much more prominent and we cannot use different ones (or at least the documentation suggests that we cannot).

Major concerns:
1. `api` will always be affected with `major-feature` and `feature` and maybe `enhancement`. It is ambiguous for us where to put these and possibly confusing to users.
2. There is not really a good place to put maintenance PRs and people would probably put them into `enhancement` (which it is not) and `fix` (which it is not).

### Suggest a potential alternative/fix

Discuss which (non-overlapping) categories are needed/wanted.

COMMENT:
> In general, deprecation PRs or changing error messages could be seen as MNT.

This is typically the usage of the "API" category because this is to announce a future incompatible API change.

> I don't recall a case where a maintenence PR required a changelog though, do we have them?

I agree that most of the time, what we call maintenance comes back to changes that do not affect a directly our end user and therefore land into the changelog. I still have the impression that it occurs in the past thought but I don't exactly have a good example on the top of the head.

Labels: Documentation
Towncrier categories overlap

### Describe the issue linked to the documentation

I had first [commented](https://github.com/scikit-learn/scikit-learn/pull/30046#issuecomment-2451761128) this on an issue, but I think maybe it is worth its own issue:

These categories that are listed in the [changelog instructions](https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md):
```
    major-feature
    feature
    efficiency
    enhancement
    fix
    api
```
are overlapping and don't cover everything. 

We have used them since 2019, but now they play a much bigger role than ever. Before, we simply put [ENH] or [MNT] in front of the changelog entries, we were allowed to deviate from them if needed, and the changes were not sortable by these categories. Now they are much more prominent and we cannot use different ones (or at least the documentation suggests that we cannot).

Major concerns:
1. `api` will always be affected with `major-feature` and `feature` and maybe `enhancement`. It is ambiguous for us where to put these and possibly confusing to users.
2. There is not really a good place to put maintenance PRs and people would probably put them into `enhancement` (which it is not) and `fix` (which it is not).

### Suggest a potential alternative/fix

Discuss which (non-overlapping) categories are needed/wanted.

COMMENT:
Thinking about it, I agree that overlap is not so big of a deal for users (without overlap would be nicer though, if it's a quick thing to agree on and establish).

I can also see how maintenance PRs could fit into API.

Maybe it's not so important overall and we can close this issue.

Labels: Documentation
Towncrier categories overlap

### Describe the issue linked to the documentation

I had first [commented](https://github.com/scikit-learn/scikit-learn/pull/30046#issuecomment-2451761128) this on an issue, but I think maybe it is worth its own issue:

These categories that are listed in the [changelog instructions](https://github.com/scikit-learn/scikit-learn/blob/main/doc/whats_new/upcoming_changes/README.md):
```
    major-feature
    feature
    efficiency
    enhancement
    fix
    api
```
are overlapping and don't cover everything. 

We have used them since 2019, but now they play a much bigger role than ever. Before, we simply put [ENH] or [MNT] in front of the changelog entries, we were allowed to deviate from them if needed, and the changes were not sortable by these categories. Now they are much more prominent and we cannot use different ones (or at least the documentation suggests that we cannot).

Major concerns:
1. `api` will always be affected with `major-feature` and `feature` and maybe `enhancement`. It is ambiguous for us where to put these and possibly confusing to users.
2. There is not really a good place to put maintenance PRs and people would probably put them into `enhancement` (which it is not) and `fix` (which it is not).

### Suggest a potential alternative/fix

Discuss which (non-overlapping) categories are needed/wanted.

COMMENT:
Happy to get back to this if we find more issues with the new system though.

Labels: Documentation
Fallback value for NaN feature during classification

### Describe the workflow you want to enable

In code like this:

```python
probabilities = model.predict_proba(df)
```

where I need to predict classification probabilities from the features in the dataframe `df`, I could have NaNs. The way things are right now, the method will raise an exception and I would have to clean the dataframe myself. 

### Describe your proposed solution

I would like to have something like:

```python
probabilities = model.predict_proba(df, val_on_nan=-1, val_on_inf=2)
```

such that when the value is nan, the probability is -1 and on inf 2.

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

I have implemented this in my wrapper class:

https://github.com/acampove/dmu/blob/main/src/dmu/ml/cv_predict.py#L48
https://github.com/acampove/dmu/blob/main/src/dmu/ml/utilities.py#L17

where I patch the nans with zeros and then I replace the probabilities before the return:

https://github.com/acampove/dmu/blob/main/src/dmu/ml/cv_predict.py#L149

feel free to pick up whatever you need from my code.

### Additional context

_No response_

COMMENT:
At first, I thought that nan or inf values are handled during preprocessing but this feature would be useful for workflows that involve directly importing and testing datasets. If no one is taking this, can I work on this?

Labels: New Feature, Needs Triage
Fallback value for NaN feature during classification

### Describe the workflow you want to enable

In code like this:

```python
probabilities = model.predict_proba(df)
```

where I need to predict classification probabilities from the features in the dataframe `df`, I could have NaNs. The way things are right now, the method will raise an exception and I would have to clean the dataframe myself. 

### Describe your proposed solution

I would like to have something like:

```python
probabilities = model.predict_proba(df, val_on_nan=-1, val_on_inf=2)
```

such that when the value is nan, the probability is -1 and on inf 2.

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

I have implemented this in my wrapper class:

https://github.com/acampove/dmu/blob/main/src/dmu/ml/cv_predict.py#L48
https://github.com/acampove/dmu/blob/main/src/dmu/ml/utilities.py#L17

where I patch the nans with zeros and then I replace the probabilities before the return:

https://github.com/acampove/dmu/blob/main/src/dmu/ml/cv_predict.py#L149

feel free to pick up whatever you need from my code.

### Additional context

_No response_

COMMENT:
> At first, I thought that nan or inf values are handled during preprocessing but this feature would be useful for workflows that involve directly importing and testing datasets. If no one is taking this, can I work on this?

I am not opposed :D. You could implement something similar to what I implemented on my wrapper, that seems to work for me.

Labels: New Feature, Needs Triage
Fallback value for NaN feature during classification

### Describe the workflow you want to enable

In code like this:

```python
probabilities = model.predict_proba(df)
```

where I need to predict classification probabilities from the features in the dataframe `df`, I could have NaNs. The way things are right now, the method will raise an exception and I would have to clean the dataframe myself. 

### Describe your proposed solution

I would like to have something like:

```python
probabilities = model.predict_proba(df, val_on_nan=-1, val_on_inf=2)
```

such that when the value is nan, the probability is -1 and on inf 2.

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

I have implemented this in my wrapper class:

https://github.com/acampove/dmu/blob/main/src/dmu/ml/cv_predict.py#L48
https://github.com/acampove/dmu/blob/main/src/dmu/ml/utilities.py#L17

where I patch the nans with zeros and then I replace the probabilities before the return:

https://github.com/acampove/dmu/blob/main/src/dmu/ml/cv_predict.py#L149

feel free to pick up whatever you need from my code.

### Additional context

_No response_

COMMENT:
I'd like to work on this as well, if that's okay.

Labels: New Feature, Needs Triage
Fallback value for NaN feature during classification

### Describe the workflow you want to enable

In code like this:

```python
probabilities = model.predict_proba(df)
```

where I need to predict classification probabilities from the features in the dataframe `df`, I could have NaNs. The way things are right now, the method will raise an exception and I would have to clean the dataframe myself. 

### Describe your proposed solution

I would like to have something like:

```python
probabilities = model.predict_proba(df, val_on_nan=-1, val_on_inf=2)
```

such that when the value is nan, the probability is -1 and on inf 2.

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

I have implemented this in my wrapper class:

https://github.com/acampove/dmu/blob/main/src/dmu/ml/cv_predict.py#L48
https://github.com/acampove/dmu/blob/main/src/dmu/ml/utilities.py#L17

where I patch the nans with zeros and then I replace the probabilities before the return:

https://github.com/acampove/dmu/blob/main/src/dmu/ml/cv_predict.py#L149

feel free to pick up whatever you need from my code.

### Additional context

_No response_

COMMENT:
handling `nan`s and `inf`s is not trivial and it's not the case that one can simply replace the output of an estimator with a constant value. For instance, in `HistGradientBoosting*` estimators, we natively handle missing values and take them as _information_.

I'm glad the wrapper works for you, but in general, it's not a solution that we should be including in scikit-learn.

However, we're happy to improve supporting / handling `nan` in sklearn and there's been significant work in this front in the past years. Very happy to have your contributions on specific estimators as well :)

Labels: New Feature, Needs Triage