Forgive me, I'm caught up in some other foss project. Fergal as ever, is bang on the money, don't break the existing NuPIC. This is a hard fork, decisions should be made with a mind to a future of neocortical machine learning. Ideally we need to architect this so that it lives on beyond our lifetimes. GPL3 + C3 will allow this. Once ready Grok will be ported to this. Decisions are made independently of Grok. I echo Fergal. Grok must accord to the best decisions for nupic. It's easy to say Grok will put food on the table, but to put Grok first won't work.
The decisions made now will have a great impact on the future of our society. Lets engineer this so the clean efficient biomimiced code can go _everywhere_. Some important (in my view) points: * no dependencies. * (strongly) consider using C for nupic-core (or nupic.core whatever the chosen name might be) (C keeps you close to the hardware, it prevents you from getting lost in hierarchies of inheritance. Side note, zeromq regretted not using C, Torsvalds of Linux thinks C++ is Satan's spawn) ** it'll be faster * ideally we don't create clients. (nupic-core <- python binding <- py-client) we just create a bindings (obviously in library form and in a separate repo from core), folks include the binding into their application and get neocortical machine learning. Don't bother shipping executable binaries. Grok is your only executable. The new API will either sink you (if badly designed) or turn you into machine learning superstars (if well designed) * it _has_ to be easy to create bindings in different languages. Absolute requirement. * There should be a selected set of popular numenta backed bindings, the rest are community backed. (maybe have a naming convention so that the greater community don't get confused) * document that new API, absolutely lather it on. Think Body Chocolate. * core will most likely be a static library. Though I'm noticing more modern day Linux distributions frown on the use of static libraries (Arch Linux + NixOS). * encoders, regions and classifiers in the core repo. ** variations of encoders and regions all go into core. Try to find patterns and don't just explode the repo because the community found a cool gizmo encoder. Expand component variety using the creative extension principle, under guidance from neuroscientists. ** testing framework from the get go, speak to J.Hawkins and more clued up community members to decide on most efficient testing mechanism. Francisco has excellent ideas here. Testing framework must be under the same license. ** the execution graph or network will be constructed in the host (application). ** the host will create loops to feed the encoders data, encoders dutifully pass outputs to whomever it is programmed to send it to. * SDR creation must have a prominent place in core. don't be surprised if people use core solely to get access to SDR creation. * formalize naming. Ie is a region or CLA etc document and elaborate, we're communicating difficult terminology. * each entity/component (encoder, region, classifier) can snap together like Lego bricks, they know how to talk to each other without some external entity. (maybe you'll need the language binding to know about it? Not sure yet, but really that's about it - no network manager etc) ** this means using bounded buffers in-between components. * The community must allocate more mindshare to nupic during this phase. Kind regards Stewart
_______________________________________________ nupic mailing list [email protected] http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
