svs14
commented
9 years ago 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
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?