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

Model interface design #1

Closed
fkiraly opened this issue Nov 8, 2018 · 2 comments
Closed

Model interface design #1

fkiraly opened this issue Nov 8, 2018 · 2 comments

Comments

@fkiraly
Copy link

fkiraly commented Nov 8, 2018

This is in reference to the "adding new models" interface design document, and in reaction to earlier request for comments.

Personally, I like:

  • the struct-dispatch architecture (probably has to be like that in Julia)
  • learners being parametric structs
  • the fit/predict methods

Things I like less or would like to highlight:

  • I think we need user interaction studies for major use cases: fitting/prediction, and benchmarking; and any minor use cases. What would we expect a user to type in the console?
  • there is no abstract hyper-parameter interface. This makes abstract higher-order operations such as tuning difficult.
  • Interface splits into X and y and seems to implicitly assume these are arrays. Should we: (a) pass only a single object plus a target specifier instead? (b) assume a data frame like structure instead? I.e., with typed and type-aware columns.
  • learners are parametric with intended variable type being a matrix/vector. I would instead go with specifying "allowed input/output column types" for column-typed data containers.
  • output type of predict_proba needs clarification. We should avoid sth hacky such as multiplying columns, per class, and end up case-dependent interfaces such as mlr. Suggestion: output row with simplex/pmf object
  • I still don't understand the use case of fit2, or why this should be a single interface point. Would suggest to split into (i) inference (ii) updateParams (iii) updateData interface points. These are not the same use case!
  • Also, if fit2 (or whatever) is supposed to be an efficient interface point for altering hyper-parameters in a fitted model, or get post-fitting functionality, wouldn't one need to pass a fitresult struct rather than a ConcreteModel?
  • in any case, fit2 doesn't seem to be necessary for MVP, so park and revisit?
@vollmersj
Copy link

I think the data container is likely to be something like https://github.com/queryverse/IterableTables.jl. For the hyperparameter interface it can be as simple as old mlj or involved as in mathematical optimisation

http://www.juliaopt.org/MathOptInterface.jl/stable/apimanual.html#Variables-1

@ablaom
Copy link
Owner

ablaom commented Nov 9, 2018

Closed, as duplicate of JuliaAI/MLJ.jl#16

@ablaom ablaom closed this as completed Nov 9, 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

No branches or pull requests

3 participants