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

Refactoring + Learn.jl #4

Open
rofinn opened this issue Mar 14, 2015 · 2 comments
Open

Refactoring + Learn.jl #4

rofinn opened this issue Mar 14, 2015 · 2 comments

Comments

@rofinn
Copy link

rofinn commented Mar 14, 2015

So with regard to restructuring this package I was thinking that we could generalize your learner type hierarchy and maybe move that into a base machine learning package like Learn.jl (should probably be LearnBase.jl, so that Learn.jl can be a meta package which installs suite of machine learning packages). After that we could probably flush out the Orchestra.jl container types for general ensemble learning composition and migrate specific implementations into their own packages. I can probably get started on the first step right away if that seems like a reasonable course of action?

@svs14
Copy link
Owner

svs14 commented Mar 15, 2015

A learner type hierarchy would definitely be worth exploring.
Great idea on separating the ML API and a meta package for installation/support (easy enough to install ML packages that can directly support the API, with wrappers for those that don't in the same package)!

As a strange as it sounds, I may not be using type hierarchies at all for separating Orchestra transformers/learners in the next release, currently experimenting with the use of declared capabilities for each transformer (will try to get this up ASAP through feature/restructure branch to better illustrate). This is mostly due to data representation + and nuanced differences between learners across different packages, of which Orchestra as a system should handle.

Agreed, a number of components of Orchestra should probably be separated into individual packages.

In terms of an immediate course of action, IMO your current type hierarchy found in Learn.jl might be more suitable as a foundation for a base machine learning package. An interesting possibility could be investigating what best data representation is required, I'd be happy to explore this with you along with associated matters through Learn.jl.

I'm going to keep this issue open for now, closing if this discussion migrates elsewhere.

@tbreloff
Copy link

@svs14 @Rory-Finnegan We've been having a very similar discussion over at JuliaML/LossFunctions.jl#2... it would be great if you could weigh in and also let us know if you might envision Orchestra merging into or using a shared framework/API. If you've been working on a redesign, maybe yours could be the basis for LearnBase.jl?

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