Feedback is being sought on a new, detailed proposal, called LearnAPI.jl , for a general purpose low-level machine learning interface. The proposal is based on our three years’ experience developing and maintaining the machine learning toolbox MLJ.jl . Ultimately, it may replace the current foundation…

Please see this announcement for the first stable release of LearnAPI.jl

Looks great @CameronBieganek , love this flexibility. My 2 cents: I’d prefer modelfit, report = fit(model, X, y). The report is some container of model metrics/diagnostics. I think it’s cleaner that modelfit contains whatever is required for predict and no more. In practical terms, I’m working on a…

The original proposal that I made above includes a minimize method for extracting only the parts of a model that are needed for prediction. (The name is up for debate.) That’s definitely useful when persisting a model to disk. Would that satisfy your requirements? I think it is conceptually cleaner…

[image] CameronBieganek: minimize method for extracting only the parts of a model that are needed for prediction such a method should probably also take some kwargs or maybe dispatch on intended prediction domain, since the model may be configured differently to optimize for batch prediction …

Another case where minimize() would be different would be using a RF regression for regular predictions, where the feature importances would be informational but not required for prediction, as opposed to using a RF model where the importance is an input to another model in the pipeline to select fe…

[image] CameronBieganek: This is a bit subjective, but when designing generic APIs, I prefer to keep the concepts as sharp as possible. Objects like report or cache seem too vague and opaque to me. What can I do with a report ? I know what I can do with a modelfit : I can use it with predict to …

An updated LearnAPI.jl proposal is now live. This will be substantially different from what most participants in this discussion have seen at the repo before. The current API is an elaboration on @CameronBieganek ’s proposal, which is basically fit(algorithm, data) -> model predict(model, new_data)…

I’ve had a quick read of the proposal, and a bit of the current interface code. Overall, it looks brilliant @ablaom , so glad you’ve taken the time to continue this effort. I’ve only got a few niggles that I’d like to raise: Cameron’s minimise function I think could be better named something like t…

The name for the function that maps learning outcomes (output of fit) to something suitable for serialisation. At time of writing, this is minimise in the docs : poll

I voted for trim, but I might actually prefer shrink, which was one of the options @tecosaur mentioned.

[ANN] LearnAPI.jl - Proposal for a basement-level machine learning API

Package Announcements

DoktorMike October 2, 2024, 6:12pm 102

This is a great piece of work. Well done everyone who helped hash this out so far. I can see this unifying a lot of otherwise rather different API’S in ML packages.

Topic		Replies	Views
Taking Fitting Seriously Data plotting	39	6013	December 8, 2018
RFC: ClusteringAPI.jl Statistics statistics , data , cluster , clustering	27	1321	April 18, 2024
[ANN] LearnAPI.jl 1.0: General API for ML/statistics Package Announcements announcement , machine-learning , api	1	288	February 19, 2025
[English] `train!` or `fit!` for a ML API? Machine Learning	1	329	July 28, 2022
Automate training MLJ models Machine Learning machine-learning , mlj	14	2227	February 17, 2020

[ANN] LearnAPI.jl - Proposal for a basement-level machine learning API

Related topics