Skip to content

[MRG] API: Fix description of brier_score_loss #14123

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

Closed
wants to merge 87 commits into from

Conversation

stefan-matcovici
Copy link
Contributor

@stefan-matcovici stefan-matcovici commented Jun 19, 2019

Reference Issues/PRs
Fixes #13887

What does this implement/fix? Explain your changes.
Introduced new scorer neg_brier_loss_score to reflect the real behavior of the scorer
Added deprecation of brier_loss_score (not sure about the versions mentioned in the deprecation message 😕)
Updated documentation to reflect changes

Any other comments?

@jnothman
Copy link
Member

This is not a doc change, but an API change. Please update the title and description

@stefan-matcovici stefan-matcovici changed the title [MRG] DOC: Fix description of brier_score_loss [MRG] API: Fix description of brier_score_loss Jun 20, 2019
@ernstklrb
Copy link

I suggest the new negated metric method to be called neg_brier_score. The old function has 'loss' added to it's name to point to the fact that "lower is better". This is no longer necessary with the new method, 'loss' can be dropped.

@jnothman
Copy link
Member

jnothman commented Jun 25, 2019 via email

@amueller
Copy link
Member

amueller commented Jul 2, 2019

I think for the scorer having neg_bier_score is the right and consistent thing to do; seems like we overlooked this when doing the other deprecations. But we don't need to change the score function.

You're also adding a method to list the valid losses. I would prefer to the PR to do just one thing.

There's also another change that seems not related and not tested.

@stefan-matcovici
Copy link
Contributor Author

I am open to any other solution of printing out the list of non-deprecated scorers. As currently this method is used just in get_scorer I can move the logic just there and actually print all the scorers in case of wrong scoring method parameter

…into pr/13918

# Conflicts:
#	sklearn/metrics/tests/test_score_objects.py
@amueller
Copy link
Member

I'm fine with having the method, but I would make it private. otherwise looks good.

@stefan-matcovici
Copy link
Contributor Author

Why private? In the end don't we want the user to be able to see what are the actual valid scorers?

@amueller
Copy link
Member

Because I consider it an implementation detail and if we make anything public we need to add deprecation cycles if we ever want to change anything about it, and that's a pain.

@@ -229,8 +251,8 @@ def get_scorer(scoring):
scorer = SCORERS[scoring]
except KeyError:
raise ValueError('%r is not a valid scoring value. '
'Use sorted(sklearn.metrics.SCORERS.keys()) '
'to get valid options.' % (scoring))
'Use sorted(sklearn.metrics.valid_scorers()) '
Copy link
Contributor Author

Choose a reason for hiding this comment

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

But the message here should remain the same right?

Copy link
Member

Choose a reason for hiding this comment

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

hm you're right, that's a bit weird if we make it private.
We could just print the output of valid_scorers here. I think we removed this here at some point but I don't remember why.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

#14123 (comment)

I can't remember either. Maybe I thought the list will be too long for an error message. Now, I believe that's the easiest way and I will get rid of the valid_scorers method too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now I know why I decided to do that. We print the output of a wrong call in the documentation. https://github.com/scikit-learn/scikit-learn/pull/14123/files#diff-1a86c825aeb118f98447f3435891d362R112.
When adding a new scorer we should update the documentation every time which is not explicit at all. What do you think about going back to valid_scorers function?

Copy link
Member

@qinhanmin2014 qinhanmin2014 left a comment

Choose a reason for hiding this comment

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

thanks for the PR and sorry for the slow reply, do you have time to finish this one? @stefan-matcovici

@qinhanmin2014 qinhanmin2014 added this to the 0.22 milestone Sep 5, 2019
* DOC Link items explictly

* STY

* DOC Link another
@stefan-matcovici
Copy link
Contributor Author

Yes, I have time, I will try to finish it today

@qinhanmin2014
Copy link
Member

Yes, I have time, I will try to finish it today

thanks

@qinhanmin2014
Copy link
Member

Please add an entry to the change log at doc/whats_new/v*.rst. Like the other entries there, please reference this pull request with :pr: and credit yourself (and other contributors if applicable) with :user:.

@qinhanmin2014
Copy link
Member

@stefan-matcovici the diff looks strange, feel free to open another PR.

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

Successfully merging this pull request may close these issues.

Documentation section 3.3.1.1 has incorrect description of brier_score_loss