Yes, as Scott mentioned, it is designed with language bindings in mind. The current design facilitates using SWIG to generate language bindings. This is what we use for Python and could be used for many other languages. It would also be straightforward to add a C API layer on top of it to make this easier and remove the SWIG dependency.
--Subutai On Sat, Jan 25, 2014 at 12:47 PM, Scott Purdy <[email protected]> wrote: > > 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 > >
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
