Do not set n_features_in_ attribute before fit#6624
Merged
rapids-bot[bot] merged 7 commits intorapidsai:branch-25.06from May 8, 2025
Merged
Do not set n_features_in_ attribute before fit#6624rapids-bot[bot] merged 7 commits intorapidsai:branch-25.06from
n_features_in_ attribute before fit#6624rapids-bot[bot] merged 7 commits intorapidsai:branch-25.06from
Conversation
viclafargue
approved these changes
May 6, 2025
jcrist
approved these changes
May 6, 2025
Member
jcrist
left a comment
jcrist
left a comment
There was a problem hiding this comment.
Thanks for the fix! LGTM (once tests pass).
Coincidentally, I noticed this in the estimator proxy refactor PR where we wanted a simple way to check if an estimator has been fit before or not. Since all cuml estimators always had n_features_in_ set, using sklearn's check_is_fitted wasn't sufficient there either. There's a lot of other places in cuml where fitted attributes will return None if unset, so this PR alone isn't sufficient to resolve that, but it's a step in the right direction.
I'd agree that this is non-breaking. I doubt anyone is relying on the current behavior, and if they are their usage doesn't follow sklearn conventions so I'd consider it a bug fix.
More estimators now pass `check_is_fitted`
Member
Author
|
/merge |
Ofek-Haim
pushed a commit
to Ofek-Haim/cuml
that referenced
this pull request
May 13, 2025
Fixes rapidsai#6528 Scikit-learn compatible estimators should not set fitted attributes (those ending in a `_`) before they are fit. In the reported case the problem occurs because `skore` uses `check_is_fitted` from scikit-learn to decide if the estimator passed in is already fitted or not. This check looks for the presence of fitted attributes. This means the random forest model appeared to be fitted, when it wasn't. What is the right label for a bug fix like this? While it does "break" existing user code that erroneously relies on this attribute always existing, that is buggy code as well. Hence I'd classify it as a bug fix. But it seems like I can only choose between non-breaking and breaking? Authors: - Tim Head (https://github.com/betatim) - Simon Adorf (https://github.com/csadorf) Approvers: - Victor Lafargue (https://github.com/viclafargue) - Jim Crist-Harif (https://github.com/jcrist) URL: rapidsai#6624
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #6528
Scikit-learn compatible estimators should not set fitted attributes (those ending in a
_) before they are fit. In the reported case the problem occurs becauseskoreusescheck_is_fittedfrom scikit-learn to decide if the estimator passed in is already fitted or not. This check looks for the presence of fitted attributes. This means the random forest model appeared to be fitted, when it wasn't.What is the right label for a bug fix like this? While it does "break" existing user code that erroneously relies on this attribute always existing, that is buggy code as well. Hence I'd classify it as a bug fix. But it seems like I can only choose between non-breaking and breaking?