On Sat, Jan 25, 2014 at 9:18 AM, stewart mackenzie <[email protected]>wrote:
> > > > On Sat, Jan 25, 2014 at 12:42 AM, Subutai Ahmad <[email protected]>wrote: > >> 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. >> >> The code isn't designed for language bindings is it? > It is designed exactly for that. There is a top level directory called "lang" but since we haven't been using any language other than Python I am guessing that it probably doesn't work out of the box for other languages. > > >> 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. >> > > It might be simple as it is, but can you easily create language bindings > for it? This is the important bit. > > So either a DSL is created to structure the graph and your code gets > compiled into a graph component. This approach means that you won't easily > be able to hook at a component level if need be. (For example variable time > prediction) > Another approach is to remove the network container completely. > - make all components speak the same language > - stick a bounded buffer in between them > then they will be able to operate without a network container. This means > that the host language can more easily configure the graph in any which way > they want. > > Above all, it must be easy to create language bindings. > > Without language bindings nupic doesn't spread to many languages. > > > >> 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. >> > > Please describe what you had. > > >> 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. >> >> Hopefully Jeff's ideas will go into nupic core. > > >> 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. >> > > If that happens you'll probably not have copyright. Its never a good idea > to hardfork (from a point of view of community dissatisfaction). It > shouldn't be lightly brought up as a solution (especially from the > custodian) as it could indicate a lack of appreciation towards the > community. A successful open source project has the community. If Nupic > forks and the community goes with the fork, Numenta fails. People use > Libreoffice since last I looked. Also things get nasty, its is a last > resort. A path never taken easily. > > Kind regards > Stewart > > _______________________________________________ > 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
