-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
A learner type hierarchy would definitely be worth exploring. 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 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. |
@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? |
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?
The text was updated successfully, but these errors were encountered: