Talip7/scikit-learn-issues-multilabel huggingface dataset:
Unexpected interaction between param validation and _get_tags in TweedieRegressor

Calling ``_get_tags`` on a ``TweedieRegressor`` with invalid value for the ``link`` or ``power`` parameter raises an error.
This is because the tag "requires_positive_y" is computed dynamically and depends on these 2 parameters.

It causes this CI failure https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44142&view=logs&j=c8afde5f-ef70-5983-62e8-c6b665ad6161&t=7fc5d80c-d67c-560e-65a2-6822419a270a
which happened after merging https://github.com/scikit-learn/scikit-learn/pull/23682 which adds param validation for GLMs and https://github.com/scikit-learn/scikit-learn/pull/23765 which makes the common test for param validation rely on the tags.

It brings 2 questions:
- should _more_tags in Tweedie perform validation for these 2 parameters to raise an informative error, even if it's a validation before fit ?
- would it be fine to implement an alternative to https://github.com/scikit-learn/scikit-learn/pull/23765 that does not rely on the tags, a bit like @glemaitre's first implementation ?

cc/ @glemaitre @thomasjpfan

COMMENT:
I opened https://github.com/scikit-learn/scikit-learn/pull/23811 to do the quick fix to unblock other PRs.

Labels: Bug, Validation
Unexpected interaction between param validation and _get_tags in TweedieRegressor

Calling ``_get_tags`` on a ``TweedieRegressor`` with invalid value for the ``link`` or ``power`` parameter raises an error.
This is because the tag "requires_positive_y" is computed dynamically and depends on these 2 parameters.

It causes this CI failure https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44142&view=logs&j=c8afde5f-ef70-5983-62e8-c6b665ad6161&t=7fc5d80c-d67c-560e-65a2-6822419a270a
which happened after merging https://github.com/scikit-learn/scikit-learn/pull/23682 which adds param validation for GLMs and https://github.com/scikit-learn/scikit-learn/pull/23765 which makes the common test for param validation rely on the tags.

It brings 2 questions:
- should _more_tags in Tweedie perform validation for these 2 parameters to raise an informative error, even if it's a validation before fit ?
- would it be fine to implement an alternative to https://github.com/scikit-learn/scikit-learn/pull/23765 that does not rely on the tags, a bit like @glemaitre's first implementation ?

cc/ @glemaitre @thomasjpfan

COMMENT:
> I think it makes sense for _get_tags to fail

We could also return the default tags if it fails. I don't have a strong preference.
My question was more: when it fails do we want an informative error message or just let it fail with e.g. ``'<' not supported between instances of 'str' and 'int'`` ?

Labels: Bug, Validation
Unexpected interaction between param validation and _get_tags in TweedieRegressor

Calling ``_get_tags`` on a ``TweedieRegressor`` with invalid value for the ``link`` or ``power`` parameter raises an error.
This is because the tag "requires_positive_y" is computed dynamically and depends on these 2 parameters.

It causes this CI failure https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44142&view=logs&j=c8afde5f-ef70-5983-62e8-c6b665ad6161&t=7fc5d80c-d67c-560e-65a2-6822419a270a
which happened after merging https://github.com/scikit-learn/scikit-learn/pull/23682 which adds param validation for GLMs and https://github.com/scikit-learn/scikit-learn/pull/23765 which makes the common test for param validation rely on the tags.

It brings 2 questions:
- should _more_tags in Tweedie perform validation for these 2 parameters to raise an informative error, even if it's a validation before fit ?
- would it be fine to implement an alternative to https://github.com/scikit-learn/scikit-learn/pull/23765 that does not rely on the tags, a bit like @glemaitre's first implementation ?

cc/ @glemaitre @thomasjpfan

COMMENT:
Thinking about it more, I am undecided on what the behavior should be. If we want to depend on tags, I do not think we want it to crash for invalid parameters. For the `TweedieRegressor`, we can hide the error by doing this:

```python
def _more_tags(
    try:
        base_loss = self._get_loss()
        return {"requires_positive_y": not base_loss.in_y_true_range(-1.0)}
    except (ValueError, AttributeError, TypeError):
        return {}
```

For `ColumnTransformer`, we do the same error catching behavior when we force it not to validate in `set_params`, or `get_params`:

https://github.com/scikit-learn/scikit-learn/blob/48096911e49fec5c41e3c49f1c2a7d0b65c44967/sklearn/compose/_column_transformer.py#L230-L236

For me, the ideal solution is to validate in `__init__`, but that is a longer API discussion.

Labels: Bug, Validation
Unexpected interaction between param validation and _get_tags in TweedieRegressor

Calling ``_get_tags`` on a ``TweedieRegressor`` with invalid value for the ``link`` or ``power`` parameter raises an error.
This is because the tag "requires_positive_y" is computed dynamically and depends on these 2 parameters.

It causes this CI failure https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44142&view=logs&j=c8afde5f-ef70-5983-62e8-c6b665ad6161&t=7fc5d80c-d67c-560e-65a2-6822419a270a
which happened after merging https://github.com/scikit-learn/scikit-learn/pull/23682 which adds param validation for GLMs and https://github.com/scikit-learn/scikit-learn/pull/23765 which makes the common test for param validation rely on the tags.

It brings 2 questions:
- should _more_tags in Tweedie perform validation for these 2 parameters to raise an informative error, even if it's a validation before fit ?
- would it be fine to implement an alternative to https://github.com/scikit-learn/scikit-learn/pull/23765 that does not rely on the tags, a bit like @glemaitre's first implementation ?

cc/ @glemaitre @thomasjpfan

COMMENT:
I opened https://github.com/scikit-learn/scikit-learn/pull/23812 as an alternative with the non failing _get_tags.

Labels: Bug, Validation
Unexpected interaction between param validation and _get_tags in TweedieRegressor

Calling ``_get_tags`` on a ``TweedieRegressor`` with invalid value for the ``link`` or ``power`` parameter raises an error.
This is because the tag "requires_positive_y" is computed dynamically and depends on these 2 parameters.

It causes this CI failure https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44142&view=logs&j=c8afde5f-ef70-5983-62e8-c6b665ad6161&t=7fc5d80c-d67c-560e-65a2-6822419a270a
which happened after merging https://github.com/scikit-learn/scikit-learn/pull/23682 which adds param validation for GLMs and https://github.com/scikit-learn/scikit-learn/pull/23765 which makes the common test for param validation rely on the tags.

It brings 2 questions:
- should _more_tags in Tweedie perform validation for these 2 parameters to raise an informative error, even if it's a validation before fit ?
- would it be fine to implement an alternative to https://github.com/scikit-learn/scikit-learn/pull/23765 that does not rely on the tags, a bit like @glemaitre's first implementation ?

cc/ @glemaitre @thomasjpfan

COMMENT:
I think we can consider that #23812 fixed this issue, the conclusion being that we don't want _get_tags to fail on invalid parameters

Labels: Bug, Validation
Unexpected interaction between param validation and _get_tags in TweedieRegressor

Calling ``_get_tags`` on a ``TweedieRegressor`` with invalid value for the ``link`` or ``power`` parameter raises an error.
This is because the tag "requires_positive_y" is computed dynamically and depends on these 2 parameters.

It causes this CI failure https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44142&view=logs&j=c8afde5f-ef70-5983-62e8-c6b665ad6161&t=7fc5d80c-d67c-560e-65a2-6822419a270a
which happened after merging https://github.com/scikit-learn/scikit-learn/pull/23682 which adds param validation for GLMs and https://github.com/scikit-learn/scikit-learn/pull/23765 which makes the common test for param validation rely on the tags.

It brings 2 questions:
- should _more_tags in Tweedie perform validation for these 2 parameters to raise an informative error, even if it's a validation before fit ?
- would it be fine to implement an alternative to https://github.com/scikit-learn/scikit-learn/pull/23765 that does not rely on the tags, a bit like @glemaitre's first implementation ?

cc/ @glemaitre @thomasjpfan

COMMENT:
Thanks!

Labels: Bug, Validation
Add `ref_line_kwargs` to CalibrationDisplay

### Describe the workflow you want to enable

**I would like to style the `CalibrationDisplay` reference line by passing styling arguments  via a kwargs object.**

If I need the reference line colored `'white'`, I would like to enable the following workflow:
```python
fig, ax = plt.subplots()
CalibrationDisplay.from_estimator(model, X_test, y_test, ax=ax , ref_line_kwargs={'color':'white'})
```

### Describe your proposed solution

#### 1) Add a `ref_line_kwargs` parameter to the `CalibrationDisplay.plot` method. ([Line 1092](https://github.com/scikit-learn/scikit-learn/blob/baf0ea25d6dd034403370fea552b21a6776bef18/sklearn/calibration.py#L1092))
```python
def plot(self, *, ax=None, name=None, ref_line=True, ref_line_kwargs={}, **kwargs):
```

#### 2) Pass the `ref_line_kwargs` object into `ax.plot`. ([Line 1139](https://github.com/scikit-learn/scikit-learn/blob/baf0ea25d6dd034403370fea552b21a6776bef18/sklearn/calibration.py#L1139))
```python
ax.plot([0, 1], [0, 1], "k:", label=ref_line_label, **ref_line_kwargs)
```

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

#### There are two alternatives that allow styling the reference line
1. Add a reference line manually and set `ref_line=False`
2. Add a reference line manually and set the label for the line to `'Perfectly calibrated'`

#### 1)
```python
fig, ax = plt.subplots()
ax.plot([0, 1], [0, 1], "k:", color='white')
CalibrationDisplay.from_estimator(model, X_test, y_test, ref_line=False, ax=ax)
```

#### 2)
```python
fig, ax = plt.subplots()
ax.plot([0, 1], [0, 1], "k:", label='Perfectly calibrated', color='white')
CalibrationDisplay.from_estimator(model, X_test, y_test, ax=ax)
```

### Additional context

For my current project, to generate a white reference line, I found myself copying and pasting the source code used for plotting the reference line by sklearn, and then adding the styling edits I needed. 

The primary benefit of this change would be the ability to style all of the plotted data without needing to interact with the matplotlib api. 

There appears to be an active pull request for improving the calibration plotting tools, and given the simplicity of this change, and if others agree with the request, #23748 seems like a natural place for this update.

COMMENT:
I prefer to delegate the styling to matplolib instead of adding `kwargs` here.

Labels: New Feature, module:calibration, Needs Decision - Include Feature
CI Windows py38_pip_openblas_32bit failure

https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=43998&view=logs&j=734b5312-468f-561d-b673-ced664ca0924&t=f7d15bce-29b2-54d8-4dda-fe465082bd42

- probably a global random seed thing, it failed with `global_random_seed = 50`, failing test is `test_inverse_transform[50-float32-False-10-expected_mixing_shape5]`
- no automated issue was created for this. I opened https://github.com/scikit-learn/scikit-learn/pull/23793 to tackle it
- maybe there is a similar fix to https://github.com/scikit-learn/scikit-learn/pull/23770

COMMENT:
I haven't been able to reproduce locally on my windows machine. I haven't been able to reproduce on azure pipelines with any random seed and float32 enabled (https://github.com/scikit-learn/scikit-learn/pull/23814).

What's weird is that, in the report you linked, it's not an issue of precision. It's like hard failing, `np.not_even_close` :)
```
E       AssertionError: 
E       Not equal to tolerance rtol=0.0001, atol=4.58524e-06
E       
E       Mismatched elements: 1000 / 1000 (100%)
E       Max absolute difference: 0.8851025
E       Max relative difference: 54.52348
E        x: array([[0.494602, 0.228083, 0.255474, 0.39633 , 0.377315, 0.996574,
E               0.408197, 0.771894, 0.760537, 0.310009],
E              [0.346541, 0.351765, 0.145467, 0.972665, 0.909178, 0.559957,...
E        y: array([[ 0.062796,  0.331623,  0.518387,  0.421327,  0.517457,  0.734317,
E                0.629462,  0.757446,  0.30224 ,  0.169982],
E              [ 0.033994,  0.557157,  0.426934,  0.73964 ,  0.94041 ,  0.376107,...
```

I also considered the possibility of non reproducibility of fastica even fix a fixed random seed, but it doesn't seem to be the case. The results are exactly the same when I run fastica 100 times in a row with the same seed.

I think we can assume that it was caused by a cosmic ray and close the issue 😄

Labels: Build / CI
CI Windows py38_pip_openblas_32bit failure

https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=43998&view=logs&j=734b5312-468f-561d-b673-ced664ca0924&t=f7d15bce-29b2-54d8-4dda-fe465082bd42

- probably a global random seed thing, it failed with `global_random_seed = 50`, failing test is `test_inverse_transform[50-float32-False-10-expected_mixing_shape5]`
- no automated issue was created for this. I opened https://github.com/scikit-learn/scikit-learn/pull/23793 to tackle it
- maybe there is a similar fix to https://github.com/scikit-learn/scikit-learn/pull/23770

COMMENT:
With the [latest run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44264&view=results) the failure is not happening anymore and it was not reproducible in https://github.com/scikit-learn/scikit-learn/pull/23814.

I am closing this for now. With https://github.com/scikit-learn/scikit-learn/pull/23793 merged, an issue will automatically open if this happens again.

Labels: Build / CI
⚠️ CI failed on Linux_nogil.pylatest_pip_nogil ⚠️

**CI is still failing on [Linux_nogil.pylatest_pip_nogil](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44957&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5)** (Jul 25, 2022)
- Test Collection Failure

COMMENT:
The nogil segfault was already noticed in https://github.com/scikit-learn/scikit-learn/pull/23762#issuecomment-1167465824.

```
______________ metrics/tests/test_pairwise_distances_reduction.py ______________
[gw0] linux -- Python 3.9.10 /home/vsts/work/1/s/testvenv/bin/python
worker 'gw0' crashed while running 'metrics/tests/test_pairwise_distances_reduction.py::test_memmap_backed_data[euclidean-PairwiseDistancesArgKmin]'
______________ metrics/tests/test_pairwise_distances_reduction.py ______________
[gw2] linux -- Python 3.9.10 /home/vsts/work/1/s/testvenv/bin/python
worker 'gw2' crashed while running 'metrics/tests/test_pairwise_distances_reduction.py::test_memmap_backed_data[euclidean-PairwiseDistancesRadiusNeighborhood]'
```

This is not deterministic and we were not able to reproduce locally, not sure what to do about it ...

Labels: Build / CI
⚠️ CI failed on Linux_nogil.pylatest_pip_nogil ⚠️

**CI is still failing on [Linux_nogil.pylatest_pip_nogil](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44957&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5)** (Jul 25, 2022)
- Test Collection Failure

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=45014&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5) on Jul 26, 2022

Labels: Build / CI
⚠️ CI failed on Linux_nogil.pylatest_pip_nogil ⚠️

**CI is still failing on [Linux_nogil.pylatest_pip_nogil](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44957&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5)** (Jul 25, 2022)
- Test Collection Failure

COMMENT:
The last time this job failed was 7 days ago. Since then the test has been passing.

Labels: Build / CI
⚠️ CI failed on Linux_nogil.pylatest_pip_nogil ⚠️

**CI is still failing on [Linux_nogil.pylatest_pip_nogil](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44957&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5)** (Jul 25, 2022)
- Test Collection Failure

COMMENT:
The failure still happens from time to time e.g. July 15 and July 22 (clicking on "edited" in the top post) ...

Labels: Build / CI
⚠️ CI failed on Linux_nogil.pylatest_pip_nogil ⚠️

**CI is still failing on [Linux_nogil.pylatest_pip_nogil](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44957&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5)** (Jul 25, 2022)
- Test Collection Failure

COMMENT:
Looking a bit closer, it seems like all the failing builds have in common that the architecture is SkylakeX but that the scipy shipped openblas (quite old 3.3 for some reason) detect the architecture as Prescott. On the succesful builds, the detected architecture is Haswell. Maybe this is loosely related to https://github.com/scikit-learn/scikit-learn/issues/21361. 

### Failing build

(e.g. [1](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44957&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5&t=653e8520-555e-5c53-897b-d98df273bc1b), [2](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44578&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5&t=653e8520-555e-5c53-897b-d98df273bc1b), [3](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44957&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5&t=653e8520-555e-5c53-897b-d98df273bc1b), [4](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44910&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5&t=653e8520-555e-5c53-897b-d98df273bc1b))

```
threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/vsts/work/1/s/testvenv/lib/python3.9/site-packages/numpy.libs/libopenblas64_p-r0-7cf8cb25.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 2

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/vsts/work/1/s/testvenv/lib/python3.9/site-packages/scipy.libs/libopenblas-r0-f650aae0.3.3.so
        version: None
threading_layer: disabled
   architecture: **Prescott**
    num_threads: 1

       user_api: openmp
   internal_api: openmp
         prefix: libgomp
       filepath: /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
        version: None
    num_threads: 2
```

### Succeeding build:
```
threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/vsts/work/1/s/testvenv/lib/python3.9/site-packages/numpy.libs/libopenblas64_p-r0-7cf8cb25.3.18.so
        version: 0.3.18
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 2

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: /home/vsts/work/1/s/testvenv/lib/python3.9/site-packages/scipy.libs/libopenblas-r0-f650aae0.3.3.so
        version: None
threading_layer: disabled
   architecture: **Haswell**
    num_threads: 1
```

Labels: Build / CI
⚠️ CI failed on Linux_nogil.pylatest_pip_nogil ⚠️

**CI is still failing on [Linux_nogil.pylatest_pip_nogil](https://dev.azure.com/scikit-learn/scikit-learn/_build/results?buildId=44957&view=logs&j=67fbb25f-e417-50be-be55-3b1e9637fce5)** (Jul 25, 2022)
- Test Collection Failure

COMMENT:
I'm closing this given #23994 is merged and https://github.com/colesbury/nogil-install/issues/2 is fixed.

The CI will open another issue if this happens again.

Labels: Build / CI
Undefined behaviour while checking if a class variable contains a model

### Describe the bug

I want to check whether a class variable is None or has an actual model. When I do this with the RandomForestRegressor, it outputs a ```AttributeError: 'RandomForestRegressor' object has no attribute 'estimators_'```. 
I have tried the same code with  ```KNeighborsRegressor```and ``` DecisionTreeRegressor```, and it works perfectly fine.
I am not sure if I am writing some sketchy code or if it is an actual bug. 

### Steps/Code to Reproduce

```python
import numpy as np
from sklearn.ensemble import RandomForestRegressor
rng = np.random.RandomState(42)
X = rng.random_sample(size = (10,3))
y = rng.random_sample(size = (10,111_000))

reg_model = RandomForestRegressor() # reg_model has a default value equal to None
if not reg_model: # it works fine if I write it as   if reg_model == None
    raise ValueError("Empty model")
    
reg_model.fit(X,y)

```

### Expected Results

The model should be fitted with no issues.

### Actual Results

```
AttributeError                            Traceback (most recent call last)
/var/folders/48/24339c8s5kz5w1b69kc65hlw0000gn/T/ipykernel_86772/4046254743.py in <module>
      1 reg_model = RandomForestRegressor()
----> 2 if not reg_model:
      3     raise ValueError("Empty model")
      4 
      5 reg_model.fit(X,y)

/usr/local/Caskroom/miniconda/base/envs/tfm/lib/python3.9/site-packages/sklearn/ensemble/_base.py in __len__(self)
    178     def __len__(self):
    179         """Return the number of estimators in the ensemble."""
--> 180         return len(self.estimators_)
    181 
    182     def __getitem__(self, index):

AttributeError: 'RandomForestRegressor' object has no attribute 'estimators_'
'''

### Versions

```shell
System:
    python: 3.9.7 (default, Sep 16 2021, 08:50:36)  [Clang 10.0.0 ]
executable: /usr/local/Caskroom/miniconda/base/envs/tfm/bin/python
   machine: macOS-10.16-x86_64-i386-64bit

Python dependencies:
          pip: 21.2.4
   setuptools: 58.0.4
      sklearn: 1.0.2
        numpy: 1.22.3
        scipy: 1.8.0
       Cython: None
       pandas: 1.4.2
   matplotlib: 3.5.1
       joblib: 1.1.0
threadpoolctl: 3.1.0

Built with OpenMP: True
```

COMMENT:
To know if an estimator is fitted, you should use: https://scikit-learn.org/stable/modules/generated/sklearn.utils.validation.check_is_fitted.html

Labels: Bug, Needs Triage