Skip to content

ENH kind accept a list of str in plot_partial_dependence #19438

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 41 commits into from
Feb 17, 2022

Conversation

glemaitre
Copy link
Member

closes #19305

This PR proposes that:

  • kind supports a list of str of the same length as features to specify different PD plots for each axis.
  • When a kind="both" and a 2-way partial dependence is requested in feature, a warning is raised instead of not making any plot. The warning will stipulate to pass a list to silence it.

@glemaitre
Copy link
Member Author

@thomasjpfan @NicolasHug This should make the job I think.

Copy link
Member

@NicolasHug NicolasHug left a comment

Choose a reason for hiding this comment

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

Thanks , gave it a quick look

@NicolasHug
Copy link
Member

Basically I see the new features of specifying a list as unrelated to the warning / error mechanism.

In fact, I feel like this list syntax is the "natural" way of specifying kind when features is also a list, and that passing a single str is just syntaxic sugar.

@glemaitre
Copy link
Member Author

Basically I see the new features of specifying a list as unrelated to the warning / error mechanism.

This is one of the reason that I have 2 entries in the what's new. I can split the PR into 2. One to support the list as an enhancement and another one as a "bug" fix that introduce the warning. It will not make a huge change in the review process thought.

@NicolasHug
Copy link
Member

I agree a single PR is fine, I was trying to explain my reasoning behind #19438 (comment) :)

Copy link
Member

@thomasjpfan thomasjpfan left a comment

Choose a reason for hiding this comment

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

Code looks good. One question about the API

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.

Here is a suggestion regarding introducing validation on kind.

Copy link
Member

@ogrisel ogrisel left a comment

Choose a reason for hiding this comment

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

Some feedback. I think several comments and messages need to be adapted to be consistent with the decision to switch from a warning to an exception:

@glemaitre glemaitre added this to the 1.1 milestone Jan 26, 2022
@glemaitre
Copy link
Member Author

gentle ping to @ogrisel @thomasjpfan

Comment on lines 417 to 418
- |Enhancement| :class:`linear_model.RidgeClassifier` is now supporting
multilabel classification.
Copy link
Member

Choose a reason for hiding this comment

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

Unrelated whats new entries. Could be related to #21516 ?

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 moved them because they were not in the right section.

Copy link
Member

Choose a reason for hiding this comment

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

Ah I see. Usually we do not do clean whats new clean ups in feature PRs?

Copy link
Member Author

Choose a reason for hiding this comment

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

OK let me revert it and I will make a push the merging day in main.

Comment on lines +1475 to +1478
default_pd_lines_kws = {
"color": "tab:orange",
"linestyle": "--",
}
Copy link
Member

@thomasjpfan thomasjpfan Feb 15, 2022

Choose a reason for hiding this comment

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

Instead of deleting ice_lines_kw["label"] here, I think we can set label here:

Suggested change
default_pd_lines_kws = {
"color": "tab:orange",
"linestyle": "--",
}
default_pd_lines_kws = {
"color": "tab:orange",
"linestyle": "--",
"label": "average"
}

Copy link
Member Author

Choose a reason for hiding this comment

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

it is not enough because "label" is part of default_line_kws

Copy link
Member Author

Choose a reason for hiding this comment

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

The problem comes if a user provides a "label" key when calling plot to overwrite the label. Then we need to delete the key in some cases.

Copy link
Member

Choose a reason for hiding this comment

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

I forgot to finish the thought. I thought we could leave the label out of default_line_kws too, since it only applies to default_pd_lines_kws.

The problem comes if a user provides a "label" key when calling plot to overwrite the label. Then we need to delete the key in some cases.

I think I see what you mean. If line_kw has a "label", then we want to remove the label for ice plots?

Scrolling up I see this is the same logic we had before, so I am okay with keeping it as is.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep exactly

glemaitre and others added 2 commits February 16, 2022 11:12
Co-authored-by: Thomas J. Fan <thomasjpfan@gmail.com>
Copy link
Member

@thomasjpfan thomasjpfan left a comment

Choose a reason for hiding this comment

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

LGTM

Comment on lines 417 to 418
- |Enhancement| :class:`linear_model.RidgeClassifier` is now supporting
multilabel classification.
Copy link
Member

Choose a reason for hiding this comment

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

Ah I see. Usually we do not do clean whats new clean ups in feature PRs?

Comment on lines +1475 to +1478
default_pd_lines_kws = {
"color": "tab:orange",
"linestyle": "--",
}
Copy link
Member

Choose a reason for hiding this comment

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

I forgot to finish the thought. I thought we could leave the label out of default_line_kws too, since it only applies to default_pd_lines_kws.

The problem comes if a user provides a "label" key when calling plot to overwrite the label. Then we need to delete the key in some cases.

I think I see what you mean. If line_kw has a "label", then we want to remove the label for ice plots?

Scrolling up I see this is the same logic we had before, so I am okay with keeping it as is.

@glemaitre
Copy link
Member Author

So I am waiting for the CI and I will merge. I will make a subsequent PR to solve the misordering of the changelog

@glemaitre glemaitre merged commit 111c782 into scikit-learn:main Feb 17, 2022
thomasjpfan added a commit to thomasjpfan/scikit-learn that referenced this pull request Mar 1, 2022
…n#19438)

Co-authored-by: Julien Jerphanion <git@jjerphan.xyz>
Co-authored-by: Thomas J. Fan <thomasjpfan@gmail.com>
Co-authored-by: Olivier Grisel <olivier.grisel@ensta.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Limitation of ICE when required for 1D and 2D interactions
5 participants