Skip to content

Full scope of API review #583

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
8 tasks done
Zruty0 opened this issue Jul 26, 2018 · 2 comments
Closed
8 tasks done

Full scope of API review #583

Zruty0 opened this issue Jul 26, 2018 · 2 comments
Labels
API Issues pertaining the friendly API

Comments

@Zruty0
Copy link
Contributor

Zruty0 commented Jul 26, 2018

Let us list all issues that we want to handle during the work on 'final user API for ML.NET'.

This way we can scope it to something of a finite project, a point that @shauheen brought up.

So, we spoke with @TomFinley today and arrived at this list. After all the below is done, we can safely call it the 1.0 API.

  • (Three major concepts: Estimators, Transformers and Data #581) Estimators and Transformers
    • The most challenging part is how to expose the most complicated components, like validating trainers, ensembles, model inspectability etc. through this. It might not even be possible.
    • This work also includes more convenience constructors, like the work in Proposal for Major Change in API #371
  • (Direct API: Static Typing of Data Pipelines #632) Type-checked pipelining. This is @TomFinley 's idea for compile-time schema propagation.
  • (TBD) Saving and loading transformer models. Make sure that we can save and load models with the same expressive power as before, using the new API.
  • (Replace SubComponent with IComponentFactory #585) Replace SubComponent with IComponentFactory. The only place where dependency injection will take place in the API is during model loading. We are going to remove the remnants of the old string-based system (SubComponents) in favor of the new one.
    • Completely removing SubComponents will probably be breaking the 'maml.exe commandline language', so we'll have to make some decision here.
  • (TBD) Move our type system closer to the C# one.
    • Replace DvXXX with native C# types wherever possible. This means DvInts into integers, DvTimeSpan into TimeSpan etc.
    • Potentially use Nullable<> to provide missing values to types that don't have them.
    • (What to do with VBuffer? #608) Consider splitting VBuffer into two types SparseVector and DenseVector.
    • If the above is done, the only difference between our type systems will be our vectors (sparse or dense, fixed or variable), and key types.

Again, if we do all of the above, we can safely call it API v1.

@TomFinley @shauheen @ericstj @eerhardt

@eerhardt
Copy link
Member

Of all the tasks above, #581 is the only one left open and not fully resolved (it is obviously very far along). I think once #581 is closed, we can close this issue as well.

@Zruty0
Copy link
Contributor Author

Zruty0 commented Dec 18, 2018

Closing this

@Zruty0 Zruty0 closed this as completed Dec 18, 2018
@ghost ghost locked as resolved and limited conversation to collaborators Mar 29, 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

2 participants