Skip to content

TST check multilabel common check for supported estimators #19859

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

Merged
merged 22 commits into from
Aug 6, 2021

Conversation

glemaitre
Copy link
Member

@glemaitre glemaitre commented Apr 10, 2021

Toward fixing #2451

Create a common test to check the output format of predict, predict_proba, and decision_function for classifiers supporting multilabel-indicator.

  • add the "multilabel" tag to classifiers that are supposed to support this format. Uses a mixin similarly to MultiOutputMixin.
  • create tests that will check the consistency of predict, predict_proba, and decision_function

@glemaitre glemaitre added No Changelog Needed module:test-suite everything related to our tests labels Apr 12, 2021
@glemaitre
Copy link
Member Author

I should check if we should add ClassifierChain and MultiOutputClassifier.

@glemaitre
Copy link
Member Author

I should check if we should add ClassifierChain and MultiOutputClassifier.

After investigation, these classifiers would requires to activate the common test for them and will increase the size of this PR.
We can create a subsequent PR to address these two classifiers.

Copy link
Member

@adrinjalali adrinjalali left a comment

Choose a reason for hiding this comment

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

I also wonder if we want to have a test making sure that the estimators you're changing (setting the estimator tag) are actually tested. (kinda making sure the tags themselves are correctly tested I guess?)

@@ -2120,6 +2123,114 @@ def check_classifiers_multilabel_representation_invariance(
assert type(y_pred) == type(y_pred_list_of_lists)


@ignore_warnings(category=FutureWarning)
def check_classifiers_multilabel_format_output(name, classifier_orig):
Copy link
Member

Choose a reason for hiding this comment

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

do we have a test to check that predict and argmax(predict_proba) are consistent?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not in this PR but it should be another additional check. I thought to have program it in the past (and it fails :)) but I cannot find any PR.

Copy link
Member

@jjerphan jjerphan left a comment

Choose a reason for hiding this comment

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

I left some comments as a newcomer to this aspect of the code-base.

@adrinjalali
Copy link
Member

Thanks for you reviews @jjerphan . Just a note that if you "Start a review", and then leave all your comments and then "submit your review" at the end, we'll get a single email notification with all of them instead of a single email for each comment you leave here. Generally I'd recommend avoiding "leave a single comment" as much as you can :)

@jjerphan
Copy link
Member

Thanks for highlighting it, @adrinjalali. I felt like I was initially going to submit only one comment.

I do agree, can relate for this inconvenience and will definitely submit comments in batches in the future.

@glemaitre
Copy link
Member Author

Uhm it seems that I broke all CIs?

@glemaitre
Copy link
Member Author

@jjerphan Actually I split the test into three small tests that are maybe easier to read.

@glemaitre
Copy link
Member Author

@jjerphan @adrinjalali I think this is good to be reviewed again.

Copy link
Member

@jjerphan jjerphan left a comment

Choose a reason for hiding this comment

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

A few last comments and suggestions.

Co-authored-by: Julien Jerphanion <git@jjerphan.xyz>
Copy link
Member

@jjerphan jjerphan left a comment

Choose a reason for hiding this comment

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

Thanks @glemaitre, this LGTM!

Copy link
Member

@adrinjalali adrinjalali left a comment

Choose a reason for hiding this comment

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

I haven't checked if all the ones which support multilable are actually included in this PR, but otherwise LGTM.

Comment on lines +38 to +54
from sklearn.utils.estimator_checks import (
_NotAnArray,
_set_checking_parameters,
check_class_weight_balanced_linear_classifier,
check_classifier_data_not_an_array,
check_classifiers_multilabel_output_format_decision_function,
check_classifiers_multilabel_output_format_predict,
check_classifiers_multilabel_output_format_predict_proba,
check_estimator,
check_estimator_get_tags_default_keys,
check_estimators_unfitted,
check_fit_score_takes_y,
check_no_attributes_set_in_init,
check_regressor_data_not_an_array,
check_outlier_corruption,
set_random_state,
)
Copy link
Member

Choose a reason for hiding this comment

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

am I the only one who prefers a single line per import kinda style instead of this? 😁

Copy link
Member

Choose a reason for hiding this comment

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

The main pro of this convention is that it groups the symbols of a module or a submodule in one place, though there's no (automatic) hard checks on whether there are other imports from the same module or submodule somewhere else.

I prefer this style, but I agree that this adds yet another style in the codebase, which is something we might want to avoid. I don't have a strong opinion. 🙂

Copy link
Member

Choose a reason for hiding this comment

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

We could also just try to have the imports from the same module one after the other, which is what we try to do in other places anyway :D

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 am not preferring anything-anymore with black :)

@glemaitre
Copy link
Member Author

@rth do you want to merge this one. It only adds tests :P

Copy link
Member

@rth rth left a comment

Choose a reason for hiding this comment

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

Overall the code LGTM, but I'm not sure about the creation of a MultiLabelMixin. The whole point of tags was not to rely on class inheritance for feature detection, and adding this mixin adds somewhat redundant information between the mixin and the tag. Can't we only the update the tags for the estimators in question?

@glemaitre
Copy link
Member Author

glemaitre commented Aug 5, 2021

This is indeed a philosophical question 😎

I think that I agree with you since we try to rely more and more on tags. Mixin avoids having to add manually the tag each time at the cost of adding the mixin itself to the MRO.

Your proposal is thus as costly regarding the maintenance and certainly more explicit when reading the class declaration.
Let me do the check and check that everything works as expected.

@glemaitre glemaitre self-assigned this Aug 5, 2021
@glemaitre
Copy link
Member Author

@rth here you go.

Copy link
Member

@rth rth left a comment

Choose a reason for hiding this comment

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

Thanks, LGTM. Linting failed however..

@rth rth merged commit a44e9a8 into scikit-learn:main Aug 6, 2021
rth pushed a commit that referenced this pull request Aug 6, 2021
samronsin pushed a commit to samronsin/scikit-learn that referenced this pull request Nov 30, 2021
samronsin pushed a commit to samronsin/scikit-learn that referenced this pull request Nov 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module:test-suite everything related to our tests No Changelog Needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants