Talip7/scikit-learn-issues-multilabel huggingface dataset:
Improvements in documentation and tests for perceptron classifier

### Describe the issue linked to the documentation

The documentation and tests for the Perceptron classifier ```sklearn/linear_model/tests/test_perceptron.py``` require enhancements to improve clarity, completeness, and usability. Currently, the documentation lacks detailed explanations of the classifier's usage, parameter descriptions, and examples illustrating its functionality. This hinders users and contributors in understanding the Perceptron classifier's behavior and effectively utilizing it for their tasks.

### Suggest a potential alternative/fix

To address these issues, it is recommended to enhance the documentation and tests for the Perceptron classifier in scikit-learn. The documentation can be improved by providing comprehensive explanations of the classifier's purpose, underlying algorithm, parameter details, and their impact on the model's behavior. Additionally, practical code examples that showcase the classifier's usage with different options and datasets would greatly benefit users in understanding and applying it correctly.

Furthermore, the existing test suite should be expanded to cover a wider range of scenarios, including edge cases, corner cases, and potential pitfalls. This will help ensure the robustness and reliability of the Perceptron classifier implementation. By strengthening the test coverage, potential issues and regressions can be identified and resolved, resulting in a more stable and trustworthy classifier.

COMMENT:
Hi, i want to solve this issue. Please allow assign me this issue.

Labels: Documentation, module:linear_model
Improvements in documentation and tests for perceptron classifier

### Describe the issue linked to the documentation

The documentation and tests for the Perceptron classifier ```sklearn/linear_model/tests/test_perceptron.py``` require enhancements to improve clarity, completeness, and usability. Currently, the documentation lacks detailed explanations of the classifier's usage, parameter descriptions, and examples illustrating its functionality. This hinders users and contributors in understanding the Perceptron classifier's behavior and effectively utilizing it for their tasks.

### Suggest a potential alternative/fix

To address these issues, it is recommended to enhance the documentation and tests for the Perceptron classifier in scikit-learn. The documentation can be improved by providing comprehensive explanations of the classifier's purpose, underlying algorithm, parameter details, and their impact on the model's behavior. Additionally, practical code examples that showcase the classifier's usage with different options and datasets would greatly benefit users in understanding and applying it correctly.

Furthermore, the existing test suite should be expanded to cover a wider range of scenarios, including edge cases, corner cases, and potential pitfalls. This will help ensure the robustness and reliability of the Perceptron classifier implementation. By strengthening the test coverage, potential issues and regressions can be identified and resolved, resulting in a more stable and trustworthy classifier.

COMMENT:
Hi @saxenapriyansh. This is a bit vague. Can you point to specific parts of the documents that are not clear enough or incomplete ?

Labels: Documentation, module:linear_model
Improvements in documentation and tests for perceptron classifier

### Describe the issue linked to the documentation

The documentation and tests for the Perceptron classifier ```sklearn/linear_model/tests/test_perceptron.py``` require enhancements to improve clarity, completeness, and usability. Currently, the documentation lacks detailed explanations of the classifier's usage, parameter descriptions, and examples illustrating its functionality. This hinders users and contributors in understanding the Perceptron classifier's behavior and effectively utilizing it for their tasks.

### Suggest a potential alternative/fix

To address these issues, it is recommended to enhance the documentation and tests for the Perceptron classifier in scikit-learn. The documentation can be improved by providing comprehensive explanations of the classifier's purpose, underlying algorithm, parameter details, and their impact on the model's behavior. Additionally, practical code examples that showcase the classifier's usage with different options and datasets would greatly benefit users in understanding and applying it correctly.

Furthermore, the existing test suite should be expanded to cover a wider range of scenarios, including edge cases, corner cases, and potential pitfalls. This will help ensure the robustness and reliability of the Perceptron classifier implementation. By strengthening the test coverage, potential issues and regressions can be identified and resolved, resulting in a more stable and trustworthy classifier.

COMMENT:
> Furthermore, the existing test suite should be expanded to cover a wider range of scenarios, including edge cases, corner cases, and potential pitfalls.

Please be more specific in your report. Note that since `Perceptron` is a subclass of `SGDClassifier` we do not need to test again all the edge cases already covered in the test suite in `test_sgd.py`. As a result `test_perceptron.py` is a lot more concise. Finally we also have generic tests for error messages in `sklearn/tests/test_common.py` that apply to all scikit-learn estimators.

Labels: Documentation, module:linear_model
PowerTransformer returns inconsistent index when transform output is set globally

### Describe the bug

When the _global_ transform output is set to "pandas" via `sklearn.set_config()`, `PowerTransformer.transform()` overrides the original index of the `DataFrame` with a `RangeIndex`. This issue does not occur with other preprocessors such as `QuantileTransformer` and can produce subtle side-effects. Lastly, this issue does _not_ occur when the aforementioned global configuration is removed and the transform output is set via `PowerTransformer.set_output(transform='pandas')`.

### Steps/Code to Reproduce

```
import pandas as pd
from sklearn.preprocessing import QuantileTransformer, PowerTransformer
from sklearn import set_config
set_config(transform_output='pandas')

X = pd.DataFrame(
    {
        'col1' : {'r0' : 1., 'r1' : 2.},
        'col2' : {'r0' : 3., 'r1' : 4.}
    }
)

qt = QuantileTransformer(n_quantiles=2)
X_trans_qt = qt.fit_transform(X)

pt = PowerTransformer()
X_trans_pt = pt.fit_transform(X)

print(f'Original : {X.index}')
print(f'QuantileTransformer : {X_trans_qt.index}')
print(f'PowerTransformer : {X_trans_pt.index}')
```

### Expected Results

All three indexes should be identical.

### Actual Results

```
Original : Index(['r0', 'r1'], dtype='object')
QuantileTransformer : Index(['r0', 'r1'], dtype='object')
PowerTransformer : RangeIndex(start=0, stop=2, step=1)
```

### Versions

```shell
System:
    python: 3.11.0 | packaged by conda-forge | (main, Oct 25 2022, 06:12:32) [MSC v.1929 64 bit (AMD64)]
executable: C:\Users\jkvas\.conda\envs\chiu-lab\python.exe
   machine: Windows-10-10.0.19045-SP0

Python dependencies:
      sklearn: 1.2.2
          pip: 23.0.1
   setuptools: 67.6.0
        numpy: 1.24.2
        scipy: 1.10.1
       Cython: None
       pandas: 1.5.3
   matplotlib: 3.7.1
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: mkl
         prefix: libblas
       filepath: C:\Users\jkvas\.conda\envs\chiu-lab\Library\bin\libblas.dll
        version: 2022.1-Product
threading_layer: intel
    num_threads: 6

       user_api: openmp
   internal_api: openmp
         prefix: vcomp
       filepath: C:\Users\jkvas\.conda\envs\chiu-lab\vcomp140.dll
        version: None
    num_threads: 12
```

COMMENT:
Thank you for opening the bug report! I agree this is a bug and opened #26454 to fix it.

Labels: Bug
Human Readable Rules for Decision Tree

### Describe the workflow you want to enable

Decision Tree should give the human readable if then rules apart from tree plot and structure results.

### Describe your proposed solution

I want to add a function to extract the rules from a decision tree in a simple "If/Then" rules.

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

_No response_

### Additional context

_No response_

COMMENT:
There is already a text representation of a tree using `export_text`:

```python
from sklearn.datasets import load_iris
from sklearn.tree import DecisionTreeClassifier
from sklearn.tree import export_text

iris = load_iris()
X = iris['data']
y = iris['target']
decision_tree = DecisionTreeClassifier(random_state=0, max_depth=2)
decision_tree = decision_tree.fit(X, y)
r = export_text(decision_tree, feature_names=iris['feature_names'])
print(r)

# |--- petal width (cm) <= 0.80
# |   |--- class: 0
# |--- petal width (cm) >  0.80
# |   |--- petal width (cm) <= 1.75
# |   |   |--- class: 1
# |   |--- petal width (cm) >  1.75
# |   |   |--- class: 2
```

If you require another text based representation, [this example](https://scikit-learn.org/stable/auto_examples/tree/plot_unveil_tree_structure.html#sphx-glr-auto-examples-tree-plot-unveil-tree-structure-py) demonstrates how to navigate the tree structure.

Labels: New Feature, Needs Triage
missing __version__!

Hello,
I am trying to run the scikitlearn OMP package using the source code. Inside the "/scikit-learn-main/sklearn.base.py" module, I see a line "from . import __version__", but there is no file called __version__

Thank you.

COMMENT:
Something probably went wrong when you installed scikit-learn and it is very likely that it is not scikit-learn's fault.

I am afraid the github issue tracker is not the best place to get help on this kind of thing, so I am going to close this issue.

Don't hesitate to have a look at our [install doc](https://scikit-learn.org/stable/install.html) and our [FAQ section](https://scikit-learn.org/stable/faq.html#what-s-the-best-way-to-get-help-on-scikit-learn-usage) about where to get help on scikit-learn usage.

Labels: Needs Triage
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
> Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. https://github.com/orgs/scikit-learn/teams/core-devs Do we agree on this ?

I agree with this.

---

Are the latest version of NumPy and SciPy distributed on Ubuntu PPA the ones retaining scikit-learn from upgrading versions?

Also, I think [SPEC 0](https://scientific-python.org/specs/spec-0000/) is the new and up-to-date version of [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html). If we want scikit-learn to be SPEC 0-compliant, we might need to change the way we update the minimum version of SciPy and NumPy because scikit-learn's dependences minimum supported version are several versions behind the ones of the schedule of SPEC 0 (we should soon drop support for SciPy < 1.8 and NumPy < 1.22).

What do you think of being SPEC 0-compliant?

Labels: RFC
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
I think moving forwards to newer versions (that include improvements and bug fixes that others have worked on) is generally a good thing. At the same time forcing people to newer versions, by upping the minimum requirement, can be tricky or at least make their install story trickier (compare "just works with the Python I get from my OS and OS package manager" with "have to install conda to then install scikit-learn"). So I'd make dropping support for older versions dependent on there being a reason to drop it other than "we drop it because we can". For example being able to remove fixes that are vendored into scikit-learn, being able to use newer concepts to start a transition, etc.

So I think being SPEC0 compliant just for the sake of following SPEC0 wouldn't get me excited.

A different view on which Python versions to support is https://devguide.python.org/versions/. I think this is much slower than SPEC0. Python 3.7 is only just coming up to EOL.

Labels: RFC
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
What Tim said! :)

What are the benefits of dropping 3.8 for us?

Labels: RFC
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
I am fine with dropping support for Python 3.8:
- Scipy has already dropped support for Python 3.8 in `main` and has mentioned a rough timeline of June for its next release https://github.com/scipy/scipy/pull/17959
- numpy has already dropped Python 3.8 in `main` https://github.com/numpy/numpy/pull/22902 and according to https://github.com/scipy/scipy/pull/17959#issuecomment-1429496287, they tend to aim for a release around December/January and one around June/July
- at one point Google colab was an argument to not drop older Python versions. Looks like it is a lot more up-to-date now, e.g. the default runtime has Python 3.10 according to https://medium.com/google-colab/colab-updated-to-python-3-10-27eb02daa162

Labels: RFC
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
I'm also happy to drop 3.8, but we can do it for 1.4

Labels: RFC
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
> For example being able to remove fixes that are vendored into scikit-learn, being able to use newer concepts to start a transition, etc.

There's one vendored fix that would be dropped, see https://github.com/scikit-learn/scikit-learn/blob/4ccf41beeb9618129ddf89200e6d9540ada7f96c/sklearn/utils/fixes.py#L131-L179

It's the only one I found, and I don't think that 3.9 has features that we deseperately want to use (there's the dict update with the syntax ``d1 | d2`` but not very urgent :smile:), so I'm fine keeping 3.8 for this release

Labels: RFC
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
> Also, I think [SPEC 0](https://scientific-python.org/specs/spec-0000/) is the new and up-to-date version of [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html). If we want scikit-learn to be SPEC 0-compliant

SPEC 0 is still in draft mode, right ? I don't think it's been widely accepted yet. We've been a lot more conservative so far, so I think we'll need a slow transition if we decide to adopt it at some point

Labels: RFC
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
> Are the latest version of NumPy and SciPy distributed on Ubuntu PPA is what retains scikit-learn from upgrading versions?

Usually yes, although https://github.com/scikit-learn/scikit-learn/pull/24665 is a counter example. For numpy we used to but we now try to follow ``oldest-supported-numpy`` instead.

Labels: RFC
RFC drop support for python 3.8 ? bump min dependencies ?

The 1.3 release being scheduled for the first half of june, it's time to think about bumping the min dependencies.

Up to now we've been trying to roughly follow [NEP29](https://numpy.org/neps/nep-0029-deprecation_policy.html) regarding supported Python versions. According to this timeline we should drop support for python 3.8 in april 2023, hence for the 1.3 release. @scikit-learn/core-devs do we agree on this ?

Dropping support for python3.8 means bumping numpy min version to 1.19.3 (currently 1.17.3) according to [oldest-supported-numpy](https://github.com/scipy/oldest-supported-numpy/blob/main/setup.cfg)

Scipy min version has already been bumped in https://github.com/scikit-learn/scikit-learn/pull/24665.
Pytest has also already been bumped  in https://github.com/scikit-learn/scikit-learn/pull/26373. 
Joblib min version is just 1 release before the latest so we probably don't want to bump it yet.

Any objection or request ?

COMMENT:
Just re-read #24665, I think the loophole we ended up with is that "we want scikit-learn to work on _a_ Ubuntu LTS version". In this case it meant that 20.04 (which is a LTS) might not work, but 22.04 (also a LTS) has to work. But this was somehow more tricky because it involved ATLAS (the Ubuntu specific BLAS implementation). So for example I don't know if what we actually ended up saying is "20.04 will work, but you will have to use a different (slower) BLAS implementation".

For reference: Ubuntu 22.04 has scipy 1.8.0, numpy 1.21.5 and Python 3.10.4. Ubuntu 20.04 is still on Python 3.8.4

Repeating Gael's question: can someone think of a benefit to the project from dropping Python 3.8?

Labels: RFC