Talip7/scikit-learn-issues-multilabel huggingface dataset:
Undocumented change in tree_.value example for DecisionTreeClassifier between versions 1.3.2 and 1.4.2

### Describe the issue linked to the documentation

In the the 1.4.2 docs the [Understanding the decision tree structure page](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#understanding-the-decision-tree-structure) provides code and output in order to inspect `tree_.value`, but the tree diagram and output from the code snippet are inconsistent.

The diagram shows integer values that represent the number of records in that class at each node.
The new output from the code appears to be the percentage? of the total number of records that are in the respective class.

The [1.3.2 docs](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#what-is-the-values-array-used-here) were consistent on this page between the code output and the diagram lower describing the values array, so I expect that something changed between the versions but wasn't documented, at least here in this example.

I can't find where this change to `tree_.value` is documented and it appears to be causing confusion (see for example on [stack overflow](https://stackoverflow.com/questions/47719001/what-does-scikit-learn-decisiontreeclassifier-tree-value-do#comment138123014_47719621)) 





### Suggest a potential alternative/fix

I would suggest updating the visual and documenting more clearly what to expect from `tree_.value` for `DecisionTreeClassifier` in 1.4.2 since it is evidently different compared to 1.3.2.
I am working with some code that inspects the trees and would appreciate insight to make sure that I make the necessary adjustments to get the same values that I did with 1.3.2.

COMMENT:
Hi there! I'm new to open source, but I'm eager to dive in and help out. I came across this issue and I think I can tackle it. Could you point me in the right direction to get started?"

Labels: Documentation, Moderate, help wanted, module:tree
Undocumented change in tree_.value example for DecisionTreeClassifier between versions 1.3.2 and 1.4.2

### Describe the issue linked to the documentation

In the the 1.4.2 docs the [Understanding the decision tree structure page](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#understanding-the-decision-tree-structure) provides code and output in order to inspect `tree_.value`, but the tree diagram and output from the code snippet are inconsistent.

The diagram shows integer values that represent the number of records in that class at each node.
The new output from the code appears to be the percentage? of the total number of records that are in the respective class.

The [1.3.2 docs](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#what-is-the-values-array-used-here) were consistent on this page between the code output and the diagram lower describing the values array, so I expect that something changed between the versions but wasn't documented, at least here in this example.

I can't find where this change to `tree_.value` is documented and it appears to be causing confusion (see for example on [stack overflow](https://stackoverflow.com/questions/47719001/what-does-scikit-learn-decisiontreeclassifier-tree-value-do#comment138123014_47719621)) 





### Suggest a potential alternative/fix

I would suggest updating the visual and documenting more clearly what to expect from `tree_.value` for `DecisionTreeClassifier` in 1.4.2 since it is evidently different compared to 1.3.2.
I am working with some code that inspects the trees and would appreciate insight to make sure that I make the necessary adjustments to get the same values that I did with 1.3.2.

COMMENT:
can I work on it ?

Labels: Documentation, Moderate, help wanted, module:tree
Undocumented change in tree_.value example for DecisionTreeClassifier between versions 1.3.2 and 1.4.2

### Describe the issue linked to the documentation

In the the 1.4.2 docs the [Understanding the decision tree structure page](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#understanding-the-decision-tree-structure) provides code and output in order to inspect `tree_.value`, but the tree diagram and output from the code snippet are inconsistent.

The diagram shows integer values that represent the number of records in that class at each node.
The new output from the code appears to be the percentage? of the total number of records that are in the respective class.

The [1.3.2 docs](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#what-is-the-values-array-used-here) were consistent on this page between the code output and the diagram lower describing the values array, so I expect that something changed between the versions but wasn't documented, at least here in this example.

I can't find where this change to `tree_.value` is documented and it appears to be causing confusion (see for example on [stack overflow](https://stackoverflow.com/questions/47719001/what-does-scikit-learn-decisiontreeclassifier-tree-value-do#comment138123014_47719621)) 





### Suggest a potential alternative/fix

I would suggest updating the visual and documenting more clearly what to expect from `tree_.value` for `DecisionTreeClassifier` in 1.4.2 since it is evidently different compared to 1.3.2.
I am working with some code that inspects the trees and would appreciate insight to make sure that I make the necessary adjustments to get the same values that I did with 1.3.2.

COMMENT:
@Kaustbh feel free to open a PR.

Labels: Documentation, Moderate, help wanted, module:tree
Undocumented change in tree_.value example for DecisionTreeClassifier between versions 1.3.2 and 1.4.2

### Describe the issue linked to the documentation

In the the 1.4.2 docs the [Understanding the decision tree structure page](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#understanding-the-decision-tree-structure) provides code and output in order to inspect `tree_.value`, but the tree diagram and output from the code snippet are inconsistent.

The diagram shows integer values that represent the number of records in that class at each node.
The new output from the code appears to be the percentage? of the total number of records that are in the respective class.

The [1.3.2 docs](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#what-is-the-values-array-used-here) were consistent on this page between the code output and the diagram lower describing the values array, so I expect that something changed between the versions but wasn't documented, at least here in this example.

I can't find where this change to `tree_.value` is documented and it appears to be causing confusion (see for example on [stack overflow](https://stackoverflow.com/questions/47719001/what-does-scikit-learn-decisiontreeclassifier-tree-value-do#comment138123014_47719621)) 





### Suggest a potential alternative/fix

I would suggest updating the visual and documenting more clearly what to expect from `tree_.value` for `DecisionTreeClassifier` in 1.4.2 since it is evidently different compared to 1.3.2.
I am working with some code that inspects the trees and would appreciate insight to make sure that I make the necessary adjustments to get the same values that I did with 1.3.2.

COMMENT:
Could anyone please recommend starting points or suggest specific files I should focus on? Any insights or advice on navigating the scikit-learn codebase to find the right areas for modification would be of great help because the files have hundreds of lines of code 😢

Labels: Documentation, Moderate, help wanted, module:tree
Undocumented change in tree_.value example for DecisionTreeClassifier between versions 1.3.2 and 1.4.2

### Describe the issue linked to the documentation

In the the 1.4.2 docs the [Understanding the decision tree structure page](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#understanding-the-decision-tree-structure) provides code and output in order to inspect `tree_.value`, but the tree diagram and output from the code snippet are inconsistent.

The diagram shows integer values that represent the number of records in that class at each node.
The new output from the code appears to be the percentage? of the total number of records that are in the respective class.

The [1.3.2 docs](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#what-is-the-values-array-used-here) were consistent on this page between the code output and the diagram lower describing the values array, so I expect that something changed between the versions but wasn't documented, at least here in this example.

I can't find where this change to `tree_.value` is documented and it appears to be causing confusion (see for example on [stack overflow](https://stackoverflow.com/questions/47719001/what-does-scikit-learn-decisiontreeclassifier-tree-value-do#comment138123014_47719621)) 





### Suggest a potential alternative/fix

I would suggest updating the visual and documenting more clearly what to expect from `tree_.value` for `DecisionTreeClassifier` in 1.4.2 since it is evidently different compared to 1.3.2.
I am working with some code that inspects the trees and would appreciate insight to make sure that I make the necessary adjustments to get the same values that I did with 1.3.2.

COMMENT:
Adding a bit more context if that helps, the doc is:
https://scikit-learn.org/stable/auto_examples/tree/plot_unveil_tree_structure.html#what-is-the-values-array-used-here

Here is a screenshot highlighting some of the issues to fix:
![image](https://github.com/scikit-learn/scikit-learn/assets/1680079/c18bcf1f-dd04-457a-8d8d-1d1aeafc3245)

I guess it is a bit confusing what `plot_tree` calls `value` is a number of samples and that it doesn't match `clf.tree_.value` (that are proportions). I am not sure what would be a reasonable way forward here.

Labels: Documentation, Moderate, help wanted, module:tree
Undocumented change in tree_.value example for DecisionTreeClassifier between versions 1.3.2 and 1.4.2

### Describe the issue linked to the documentation

In the the 1.4.2 docs the [Understanding the decision tree structure page](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#understanding-the-decision-tree-structure) provides code and output in order to inspect `tree_.value`, but the tree diagram and output from the code snippet are inconsistent.

The diagram shows integer values that represent the number of records in that class at each node.
The new output from the code appears to be the percentage? of the total number of records that are in the respective class.

The [1.3.2 docs](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#what-is-the-values-array-used-here) were consistent on this page between the code output and the diagram lower describing the values array, so I expect that something changed between the versions but wasn't documented, at least here in this example.

I can't find where this change to `tree_.value` is documented and it appears to be causing confusion (see for example on [stack overflow](https://stackoverflow.com/questions/47719001/what-does-scikit-learn-decisiontreeclassifier-tree-value-do#comment138123014_47719621)) 





### Suggest a potential alternative/fix

I would suggest updating the visual and documenting more clearly what to expect from `tree_.value` for `DecisionTreeClassifier` in 1.4.2 since it is evidently different compared to 1.3.2.
I am working with some code that inspects the trees and would appreciate insight to make sure that I make the necessary adjustments to get the same values that I did with 1.3.2.

COMMENT:
I'm happy to help address this issue. For the scikit-learn core devs, can someone educate me on why we should store proportions?

I see a few paths forward:

1. when outputting the `tree_.value`, we re-weight it so that it shows the total counts. This makes everything the same as it was before
2. when outputting the `tree_.value`, we show promotions and document it accordingly. Then in `plot_tree`, we should change `value` perhaps to say `count`? That way it is ultra clear what the visualized tree is showing?

Labels: Documentation, Moderate, help wanted, module:tree
Undocumented change in tree_.value example for DecisionTreeClassifier between versions 1.3.2 and 1.4.2

### Describe the issue linked to the documentation

In the the 1.4.2 docs the [Understanding the decision tree structure page](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#understanding-the-decision-tree-structure) provides code and output in order to inspect `tree_.value`, but the tree diagram and output from the code snippet are inconsistent.

The diagram shows integer values that represent the number of records in that class at each node.
The new output from the code appears to be the percentage? of the total number of records that are in the respective class.

The [1.3.2 docs](https://scikit-learn.org/1.3/auto_examples/tree/plot_unveil_tree_structure.html#what-is-the-values-array-used-here) were consistent on this page between the code output and the diagram lower describing the values array, so I expect that something changed between the versions but wasn't documented, at least here in this example.

I can't find where this change to `tree_.value` is documented and it appears to be causing confusion (see for example on [stack overflow](https://stackoverflow.com/questions/47719001/what-does-scikit-learn-decisiontreeclassifier-tree-value-do#comment138123014_47719621)) 





### Suggest a potential alternative/fix

I would suggest updating the visual and documenting more clearly what to expect from `tree_.value` for `DecisionTreeClassifier` in 1.4.2 since it is evidently different compared to 1.3.2.
I am working with some code that inspects the trees and would appreciate insight to make sure that I make the necessary adjustments to get the same values that I did with 1.3.2.

COMMENT:
> * first fix the example to have a consistent explanation and make `value` in `plot_tree` the same as `tree_.value` (you probably need fixed width formatting similar to `{tree_.value:.3f}` to avoid long floating numbers). Note that other documentation, tutorials, etc ... may need to change, for example https://github.com/inria/scikit-learn-mooc probably will need to be adapted as well if we change the output of `plot_tree` but oh well this is OK I guess ...
> * optional: add a changelog entry in 1.4.X to say that `tree.value_` meaning changed and indicate that is a somewhat breaking change even if people are unlikely to be affected

I think the change is relatively simple at the documentation level and I've put up a PR to address these two points. `plot_tree` already accounts for the fact that `proportion` can be set as a kwarg. However, the explanation could use some augmenting.

> * medium-term, if we think this is worth it, change `tree_.value` to a more explicit name (`tree_.weighted_proportion` or something better) with a deprecation period and update plot_tree to use the new name?

I do think this is worthwhile because it it totally unclear except in this example what `tree_.value` is. It will help the Cython maintenance of `sklearn/tree` too. If this is something worth doing, I'm happy to submit a follow-on PR.

Labels: Documentation, Moderate, help wanted, module:tree
mypy errors when depending on sklearn

### Describe the workflow you want to enable

less errors when analyzing python code relying on sklearn using mypy

### Describe your proposed solution

Better code?
Typing annotations in the right places?


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

N/A

### Additional context

error: Skipping analyzing "scipy": module is installed, but missing library stubs or py.typed marker  [import-untyped]
error: Skipping analyzing "sklearn": module is installed, but missing library stubs or py.typed marker  [import-untyped]
error: Skipping analyzing "joblib": module is installed, but missing library stubs or py.typed marker  [import-untyped]
error: Skipping analyzing "sklearn.ensemble": module is installed, but missing library stubs or py.typed marker  [import-untyped]
error: Skipping analyzing "sklearn.metrics": module is installed, but missing library stubs or py.typed marker  [import-untyped]

COMMENT:
We don't really support this, additional info: https://github.com/scikit-learn/scikit-learn/discussions/25307

Labels: New Feature, Needs Triage
DOC Add Tidelift to sponsor list

### Describe the issue linked to the documentation

Add Tidelift to sponsor list https://scikit-learn.org/stable/about.html#funding

### Suggest a potential alternative/fix

_No response_

COMMENT:
Indeed.

@adrinjalali @thomasjpfan any suggestion on the phrasing?

Shall we link to https://opencollective.com/scikit-learn for extra transparency?

Note that based on https://opencollective.com/scikit-learn/transactions, the monthly payment from Tidelift seems to have been divided by 2 in March...

Labels: Documentation
DOC Add Tidelift to sponsor list

### Describe the issue linked to the documentation

Add Tidelift to sponsor list https://scikit-learn.org/stable/about.html#funding

### Suggest a potential alternative/fix

_No response_

COMMENT:
I don't mind adding Tidelift. And yes it seems from February the money is halved! I don't think we need to link to open collective.

Opened https://github.com/scikit-learn/scikit-learn/pull/28918 to address this.

Labels: Documentation
RFC Move `_more_tags` to "developer API" via `__sklearn_tags__`

As a part of making it easier and more "standard" to write scikit-learn estimators by third party developers, we have been slowly developing a "developer API" kind of thing, which are useful for third party developers, but not end users of the estimators.

Some of the work has been:
- `__sklearn_clone__`
- `__metadata_request__fit`, ...
- `get_metadata_routing`

What I'm proposing here, is to create a new `__sklearn__tags__` method instead of the existing `_more_tags`.

We've had a lot of discussions when we designed the current system, which goes through the MRO and the `_more_tags` _adds_ to the tag set instead of returning the tags. Now the question is do we want to keep the current system or do we want `__sklearn_tags__` to return the estimator's tags instead, and call parent's `__sklearn_tags__` inside itself? As in, instead of:

```py
class Estimator(BaseEstimator):
    ...
    def _more_tags(self):
        return {...}
```

to have:

```py
class Estimator(BaseEstimator):
    ...
    def __sklearn_tags__(self):
        tags = super().__sklearn_tags__()
        # update tags
        return return tags
```
Inside our tags, we also have some starting with `_` such as `_xfail`, and the question is do we want to make those _public_.

cc @scikit-learn/core-devs

COMMENT:
+1 on
> do we want `__sklearn_tags__` to return the estimator's tags

and removing `_more_tags`

Labels: API, RFC, Developer API
RFC Move `_more_tags` to "developer API" via `__sklearn_tags__`

As a part of making it easier and more "standard" to write scikit-learn estimators by third party developers, we have been slowly developing a "developer API" kind of thing, which are useful for third party developers, but not end users of the estimators.

Some of the work has been:
- `__sklearn_clone__`
- `__metadata_request__fit`, ...
- `get_metadata_routing`

What I'm proposing here, is to create a new `__sklearn__tags__` method instead of the existing `_more_tags`.

We've had a lot of discussions when we designed the current system, which goes through the MRO and the `_more_tags` _adds_ to the tag set instead of returning the tags. Now the question is do we want to keep the current system or do we want `__sklearn_tags__` to return the estimator's tags instead, and call parent's `__sklearn_tags__` inside itself? As in, instead of:

```py
class Estimator(BaseEstimator):
    ...
    def _more_tags(self):
        return {...}
```

to have:

```py
class Estimator(BaseEstimator):
    ...
    def __sklearn_tags__(self):
        tags = super().__sklearn_tags__()
        # update tags
        return return tags
```
Inside our tags, we also have some starting with `_` such as `_xfail`, and the question is do we want to make those _public_.

cc @scikit-learn/core-devs

COMMENT:
I am +1. I updated https://github.com/scikit-learn/scikit-learn/pull/22606 that implements `__sklearn_tags__`.

Labels: API, RFC, Developer API
RFC Move `_more_tags` to "developer API" via `__sklearn_tags__`

As a part of making it easier and more "standard" to write scikit-learn estimators by third party developers, we have been slowly developing a "developer API" kind of thing, which are useful for third party developers, but not end users of the estimators.

Some of the work has been:
- `__sklearn_clone__`
- `__metadata_request__fit`, ...
- `get_metadata_routing`

What I'm proposing here, is to create a new `__sklearn__tags__` method instead of the existing `_more_tags`.

We've had a lot of discussions when we designed the current system, which goes through the MRO and the `_more_tags` _adds_ to the tag set instead of returning the tags. Now the question is do we want to keep the current system or do we want `__sklearn_tags__` to return the estimator's tags instead, and call parent's `__sklearn_tags__` inside itself? As in, instead of:

```py
class Estimator(BaseEstimator):
    ...
    def _more_tags(self):
        return {...}
```

to have:

```py
class Estimator(BaseEstimator):
    ...
    def __sklearn_tags__(self):
        tags = super().__sklearn_tags__()
        # update tags
        return return tags
```
Inside our tags, we also have some starting with `_` such as `_xfail`, and the question is do we want to make those _public_.

cc @scikit-learn/core-devs

COMMENT:
> Inside our tags, we also have some starting with _ such as _xfail, and the question is do we want to make those public.

I don't see the reason why we need to have it public.

Making the switch to `__sklearn_tags__` would be a step to make the system public which is fine with me. However, I think that we also need to revisit the tags and their meaning. I'm fine with most of them but I have the following issues:

- `multioutput_only` and `multioutput` could be confusing. We should have a single tag. An alternative solution is to have a tag that contains a set of string defining the type of problems supported, e.g. `target_type = {"binary", "multiclass"}`
- `X_types` might be expanded. Maybe the refactoring of `_convert_container` in https://github.com/scikit-learn/scikit-learn/pull/28681 could help at designing a set of tags.

Labels: API, RFC, Developer API