If I understand Stewart, the benefits of splitting into separate repositories are cleanly separating the Network API and Algos, without affecting Grok dependencies such OPF. I'm new to OS development of this magnitude, so I can only ask clarifying questions - Can we get the same results in a single repo by creating a clean API and abstraction layer, clean up repo organization and tie supporting documents and examples in wiki that are clearly linked to the large chunks of discrete functionality?
I think that Grok dependencies should be abstracted out in a way that shows by example how other consumers of the API (non Grok solutions - commercial or otherwise) can use the core algorithms and Region/Network API. So Grok with the OPF would become the 'canonical' example of how to use the core and Numenta/Grok as a business entity and major stakeholder can drive how the core and core API evolves along with the community. For example, I thought I heard Jeff say in the office hours video that they are not going to use swarming anymore for many of their solutions because swarming found some optimal setting heuristics that always work well for certain problems. This could be seen as an example of the commercial use driving innovation of a toolset (OPF) that may change rapidly while the core algos remain stable. I can see other toolsets similar to the OPF that might be completely new codebases (Stewarts Flow Based Programming example). If anything needs it's own repository it would be the OPF. My vote would be to keep the Network API/Region data structures and the CLA Algos in a single repo and split out the OPF. -Doug On Sun, Nov 17, 2013 at 11:56 AM, Matthew Taylor <[email protected]> wrote: > > > On Nov 17, 2013, at 11:43 AM, Subutai Ahmad <[email protected]> wrote: > > > > Matt - what's the best way to carry on the discussion? We can keep going > on email, but would this also be a good office hour topic? > > I think we should continue the discussion here for now. The office hours > are better for non-developments topics at this time, IMO. > > Matt > _______________________________________________ > nupic mailing list > [email protected] > http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org >
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
