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

[Discussion] Support the MLDataPattern API for data containers #918

Open
ablaom opened this issue Apr 1, 2022 · 0 comments
Open

[Discussion] Support the MLDataPattern API for data containers #918

ablaom opened this issue Apr 1, 2022 · 0 comments

Comments

@ablaom
Copy link
Member

ablaom commented Apr 1, 2022

I am referring to this getobs interface which is being migrated to MLUtils.jl.

To allow for certain kinds of training using data that does not fit into memory, I should like MLJ to eventually support models that can accept data supplied by DataLoaders.jl, such as Flux models. However, I feel these models should play nicely with MLJ’s general performance evaluation (aka resampling) apparatus (eg, cross-validation) as MLJFlux models currently do. This apparatus is also used by MLJ’s IterativeModel wrapper for controlling iterative models (which needs out-of-sample performance estimates for stopping criterion, for example). However, the performance estimation apparatus has been designed principally around in-memory arrays and tabular data. This is what > 90% of models we wrap consume.

To add MLJ support for the getobs API, on which DataLoaders is based, it will be helpful if Tables.jl plays nicely with the getobs interface, something I have requested at JuliaML/MLUtils.jl#61 (see also JuliaML/MLUtils.jl#67). Related to this effort are apparent restrictions around the Tables.jl API around efficient row-indexing (the current API only exposes row iteration) - which is being actively investigated here.

Related online/incremental learning issue: #60

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

1 participant