Skip to content

Multiclass in API has many names #2623

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
rogancarr opened this issue Feb 19, 2019 · 4 comments
Closed

Multiclass in API has many names #2623

rogancarr opened this issue Feb 19, 2019 · 4 comments
Assignees
Labels
API Issues pertaining the friendly API

Comments

@rogancarr
Copy link
Contributor

When we refer to multiclass in the API, it has many names: MulticlassClassification, MultiClassClassifierMetrics are just two examples. For the V1 API, does it make sense to stick to one naming scheme?

@rogancarr rogancarr added the API Issues pertaining the friendly API label Feb 19, 2019
@TomFinley
Copy link
Contributor

TomFinley commented Feb 19, 2019

For the v0.1 API (to be clear, the one for build 2018), I think the decision made with conjunction with .NET team was that what we called internally multiclass classification would just be called classification, and we'd standardize on two-class classification as being specifically "binary classification." (As a specific important but nonetheless less general case of "classification.") I was however not here for these discussions for various reasons, so may be mischaracterizing it. @terrajobst, @eerhardt, @glebuk, @shauheen can correct me if I say something wrong.

Whether we want to do that or not, I am indifferent towards. If we go by what sklearn does, they seem to view classification as the default task, with multiclass as a more specialized task. (Which is from a machine learning perspective "correct" in that how that is how the field evolved and is still organized in some sense, but is somewhat backwards from a conceptual point of view.) Of course just because sklearn organizes itself in that way doesn't mean that we should do the same thing!! (Though I'd point out that moving in that direction would be less overall work, since internally that's how we think about ourselves as well.)

I only agree that we should be consistent, and I can only explain the reason why we're inconsistent. 😄 Which direction we choose to go... I don't know. Might want to talk to the above peeps.

@eerhardt
Copy link
Member

Yes, that was our intention with the v0.1 API last year. “Classification” and “BinaryClassification” were the names we were using in that API.

100% agree we should be consistent throughout our public API, whatever names we choose.

@shauheen
Copy link
Contributor

I understand this is YetAnotherNamingDiscussion! I have strong feelings against Classification for multiclass.

@najeeb-kazmi
Copy link
Member

I also don't like just Classification for multiclass. How about MulticlassClassification and BinaryClassification? Keeps the capitalization in Multiclass consistent with MLContext.MulticlassClassification and MulticlassClassificationCatalog.

@artidoro artidoro self-assigned this Mar 12, 2019
@ghost ghost locked as resolved and limited conversation to collaborators Mar 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
API Issues pertaining the friendly API
Projects
None yet
Development

No branches or pull requests

6 participants