8000 Change default solver in LogisticRegression and replace multi_class with multinomial by jnothman · Pull Request #11903 · scikit-learn/scikit-learn · GitHub
[go: up one dir, main page]

Skip to content

Change default solver in LogisticRegression and replace multi_class with multinomial #11903

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 21 commits into from

Conversation

jnothman
Copy link
Member
@jnothman jnothman commented Aug 23, 2018

This continues the work in #11476, but provides more flexibility to the user in whether or not softmax regression is used, by deprecating multi_class and adding a setting multinomial in {False, True, 'multiclass'}.

Some points of note:

  • other estimators including LinearSVC and GaussianProcessClassifier have a multi_class param
  • I've called the new param multinom 8000 ial but could have called it softmax or called the inverse binarized
  • I've given it the special value 'multiclass'... but this could be multi-class??

Closes #11476
Closes #10001
Closes #9997

@jnothman jnothman added this to the 0.20 milestone Aug 23, 2018
@jnothman
Copy link
Member Author

I've realised that this still needs a FutureWarning when multi_class='deprecated' and multinomial='compat' and the data is multiclass, to say that default behaviour will change to multinomial logistic...

I'm not entirely sure that deprecating multi_class is worthwhile..

@jnothman
Copy link
Member Author

Overall, I think I'm inclining towards @agramfort's position that we should just have multi_class='auto'. This would:

  • be 'ovr' if solver='liblinear' or y is binary
  • be 'multinomial' otherwise

While there's a problem of discoverability, as @amueller suggests, once the change of defaults is completed, it will be simple for most users, whereas the transition proposed here is quite confusing for users, and involves deprecating a parameter with a standard (if problematic name) to be replaced with one where there should be some debate that we do not have time for before release. If we want to deprecate multi_class after release, we can do that, but I'm inclined to go implement multi_class='auto' and aim to merge it for this much-delayed release.

@amueller
Copy link
Member

ok let's do auto.

@jnothman jnothman closed this Aug 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants
0