Matt, I agree with you and Scott - I don't think there is much Grok specific code in NuPIC. If there is, we should plan to clean it up.
My vote is the same as yours: fork and split NuPIC, transition Grok to the new structure, and evolve the API from there. As Chetan said, an incremental step is usually the best way to do a migration like this. IMO, the Network API code is very clean, simple and general purpose C++ code. We started with something a lot more complex in 2007 and rewrote it to be much simpler. It is a good base from which to evolve. Once we remove the Python portion, it will be surprisingly small and light. The other reason to do an incremental change is that during 2014 I hope we can also work on Jeff's new ideas. I am hoping the community will contribute and help out. I think those ideas will lead to significant advances in the science and prospects for intelligent computing, but there is much work to do. It will be very difficult to keep multiple code bases in sync while simultaneously working on those ideas. Having said that, there is nothing stopping anyone from forking and doing a major rewrite (per Fergal's latest email - just saw that while writing this). Grok might decide to switch to this once the new implementation is ready but we can't commit to that. --Subutai On Fri, Jan 24, 2014 at 2:33 PM, Matthew Taylor <[email protected]> wrote: > On Fri, Jan 24, 2014 at 2:10 PM, Scott Purdy <[email protected]> wrote: > >> I think that poll is a little misleading. We don't want NuPIC to be >> specific to Grok and I don't think that it is. I think there is some >> confusion about what is actually in the repository. >> > > The poll isn't about Grok-specifics inside the codebase, it's about > whether to untether the extraction from current Grok requirements. Grok is > the only real client of NuPIC at this point, so calling out this > association is exactly the point of the poll. Also, Grok provides some > amount of build security and stability because of the (invisible) > regression tests running in the Grok QA pipeline. > > >> What parts of the code are Grok-specific? >> > > If someone has been talking about Grok-specific code in NuPIC, I must've > missed it. I don't think there are any, especially within the C++. > > >> And what are the plans that will cause backwards compatibility issues? I >> don't think backwards compatibility needs to slow anything down. With the >> new SP, for instance, we left the old SP so that people (both at Grok and >> elsewhere) could gradually migrate on their own. >> > > There are no plans, as far as I know. I think people just want the option > to break or create a new API for nupic-core with this extraction. I'm in > favor of a direct fork of NuPIC's current C++ API and an evolution from > there. > > > My two primary goals as the NuPIC OS Guy are: > - Don't break Grok > - Help drive NuPIC in the direction the FOSS community wants to take it > (be a catalyst for the advancement of machine intelligence) > > In the end, if the community wants to fork NuPIC and create a core repo > themselves, there is nothing stopping them. It won't break Grok, and NuPIC > is going in the direction the community wants. > > --------- > Matt Taylor > OS Community Flag-Bearer > Numenta > > > _______________________________________________ > 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
