Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

TST improve messages raised in check_classifier_multioutput #30235

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
Loading
from

Conversation

adrinjalali
Copy link
Member

This PR improves error messages raised in check_classifier_multioutput

@adrinjalali adrinjalali added Developer API Third party developer API related No Changelog Needed labels Nov 7, 2024
Copy link

github-actions bot commented Nov 7, 2024

✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

Generated for commit: 75caa5b. Link to the linter CI: here

Comment on lines +2016 to +2018
"The prediction for multioutput data is expected to be of the same type "
f"as the input y. Got dtype={y_pred.dtype}, dtype.kind={y_pred.dtype.kind} "
f"instead, while input was dtype={y.dtype}, dtype.kind={y.dtype.kind}."
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose this is what we're testing. But not entirely sure.


if hasattr(estimator, "decision_function"):
decision = estimator.decision_function(X)
assert isinstance(decision, np.ndarray)
assert isinstance(decision, np.ndarray), (
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So here we're checking the actual type of the output of decision_function. But this seems wrong(?) when I think of the array API work. WDYT @betatim @ogrisel @OmarManzoor

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could check for xp.array?

Comment on lines -2027 to -2029
dec_pred = (decision > 0).astype(int)
dec_exp = estimator.classes_[dec_pred]
assert_array_equal(dec_exp, y_pred)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This parts is just odd to me. estimator.classes_=[0, 1, 2], and we do some fancy indexing using the results from the decision function. I can't imagine a case where this could fail, or to be meaningful, especially since the value 2 from classes_ would never be chosen here.

np.argmax(y_prob[i], axis=1).astype(int), y_pred[:, i]
)
elif not tags.classifier_tags.poor_score:
if not tags.classifier_tags.poor_score:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

decoupling the shape check from the value check, and skipping only the value check if poor_score

@adrinjalali
Copy link
Member Author

@glemaitre I think you've worked on this quite a bit in the past.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.