Nice to see the progress made towards an easy to use development platform. Flow based programming in conjunction with machine learning reminds me of the open source project KNIME (http://www.knime.org/).
Straight from their site: 'KNIME [naim] is a user-friendly graphical workbench for the entire analysis process: data access, data transformation, initial investigation, powerful predictive analytics, visualisation and reporting. The open integration platform provides over 1000 modules (nodes), including those of the KNIME community and its extensive partner network.' This or something similar would lessen the barrier of entry a lot and as a side effect it's far easier to test several implementations concurrently based on a benchmark network. 2014/1/18 Stewart Mackenzie <[email protected]> > Nothing wrong with psuedo-code for this level of 'idea->implementation' > stage. > > Dinner conversations with Francisco has stimulated constructive thoughts. > That's a special person in our community. Our approaches are slightly > different. My thoughts lean towards an environment that allows > non-developers to pivot quickly, test new brain theory, drag in the > component test then throw away if needed. This test bed becomes the source > of papers and more efficient implementations. > > Pspice, needs hardened hardware experts, a large amount of money to > purchase a license and the implementation isn't approachable to an eye > untrained in hardware design. My thoughts are we need tools that are a > delight for neuroscientists. From an open-source perspective Pspice isn't > feasible, developing a competent effective community is a primary concern, > the community will not be able to interact with the 'good stuff' if they > have high barriers of entry. Though at some later stage given a hardware > implementation is needed or more finer tests are needed then so be it, > pspice. > > I am okay with using our oz based flow based programming environment > called fractal. Probably best to read J.Morrison's "Flow Based Programming > 2nd edition" book. Currently fbp is being reignited by these guys: > noflojs.org https://www.youtube.com/watch?v=LYJxsaeHVJU . Funnily enough > Morrison has also read On Intelligence and at the back of his book he > recommends using FBP to implement numunta's nupic. Except i'd do it in a > FBP implementation using Oz, which means we can _remove the need for a > clock_, which more closely emulates the brain. (this is important: > declarative concurrency removes state / time from the picture). A cortex > implementation in fractal could become the 'whiteboard', the flow diagram > of how it fits together, the components neuroscientists, engineers and > community string together to prove and incorporate any new brain research. > It exposes the right level of complexity for non-developers that isn't > source code but only the inputs/outputs and component names. > Neuroscientists can easily give the specifications for a component which a > software developer can implement. The component implementation is clean and > modular. Specifications are easy to communicate, and the component becomes > reusable. This implementation then becomes the example implementation other > faster more efficient implementations and future academic papers are based > on. > > Many _developers_ are still stuck on getting nupic compiled and running, > now imagine neuroscientists getting into the nupic codebase to make changes > based on new theory. It won't happen. How will they test their hypotheses? > Therefore the right level of abstraction is needed for these diverse > parties. > > I'm looking forward to the rewriting of the whitepaper. I think it'll > bring the whole project into focus and get everyone on the same page. > > Kind regards > Stewart > > > > Jeff Hawkins <[email protected]> wrote: > >Thank you for all these thoughts, I am still digesting them. > > > >Part of what is motivating me to tackle documentation this year is that > >I might be closing in on a broader understanding of what all the layers > >in the cortex are doing. The CLA is just part of that. I need to > >figure out the best way(s) to communicate these new ideas. > > > >One question is what kind of language to use. In the white paper we > >used prose, pseudo-code, and neuroscience. The pseudo-code was > >intended to be a clear and somewhat formal description, immune to the > >messiness of the actual code. Yes, you need to have some programming > >skills but not much. Do you think that pseudo-code isn't sufficient as > >a formal description? > > > >The other question is where to publish. We could just write a new > >white paper, the current one is getting old anyway. The nice thing > >about a white paper is it can be as comprehensive as needed. But I am > >also feeling some pressure to publish in a peer reviewed journal. Some > >people don't take you seriously without peer review. As you suggest we > >could do a white paper and then a series of smaller papers. > > > >The Oz-based programming environment sounds cool but I have to see it > >to understand it better. > > > >Still thinking about ths... > >Jeff > > _______________________________________________ > 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
