Skip to content
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

Consistent ordering of (feature, label, groupid, weight) parameters in ML.NET trainer estimators #2662

Closed
abgoswam opened this issue Feb 20, 2019 · 1 comment
Labels
API Issues pertaining the friendly API

Comments

@abgoswam
Copy link
Member

abgoswam commented Feb 20, 2019

The public API of ML.NET should have a defined ordering for

  • feature column name
  • label column name
  • weight column name
  • group id column name

Currently the trainer estimators in ML.NET do not have a defined ordering for the above parameters. We should address this as we finalize the API for V1.0

Here is a proposal for consistent ordering of these parameters for the trainer estimators:

  1. unsupervised trainer estimators (e.g. KMeansPlusPlusTrainer)
    (feature , weight)

  2. supervised trainer estimators: (e.g. LightGbmBinaryTrainer)
    (label, feature, weight)

  3. ranking trainer estimators: (e.g. LightGbmRankingTrainer)
    (label, feature, groupid, weight)

Related to #2177, #2257, #2660

@Ivanidzo4ka @sfilipi @rogancarr @TomFinley @glebuk

@abgoswam abgoswam added the API Issues pertaining the friendly API label Feb 20, 2019
@abgoswam
Copy link
Member Author

I verified the above pattern is followed by the trainer estimators. The only exception is FieldAwareFactorizationMachine which differs in 2 ways .

  1. it accepts a string[] for featureColumnNames . other trainer estimators just take a string
  2. label is the 2nd parameter . in the other trainer estimators label is the 1st argument

Marking as closed.

@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

1 participant