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 -----Original Message----- From: nupic [mailto:[email protected]] On Behalf Of Stewart Mackenzie Sent: Tuesday, January 14, 2014 8:58 PM To: NuPIC general mailing list. Subject: Re: [nupic-discuss] Hong Kong meeting outcome please read responses inline: Francisco Webber <[email protected]> wrote: >Jeff, Steward, >I think what is actually missing is a formal description of the >algorithm that allows non software programmers to understand and >analyze it in full detail. Fergal and I were even thinking of an >electronic wiring schematic to try and capture the full detail of CLA >in a concrete formal way. I fear that without a central formal model >the theoretical research, the practical implementation and the >documentation will slowly drift apart without anyone noticing. >Having a software-development-independent formal description of the >algorithm will also help to avoid the mix-up of code-parts that are >there because the CLA algorithm says so, parts that are there because >no better engineering solution has been found yet for a specific system >behavior and even parts that might be there because of the specific >expressiveness of a programming language. We're designing and developing a flow-based programming environment on Mozart Oz. -To get to the point quickly: this tool allow us to expose a 'box-and-line' user interface to the non-programmer that can be programmed by dragging a finger on the screen. One box might be a neuron, another a dendrite another a synapse and one can 'drill down' and open up components within components (ie composite components). This allows high level display of logic without getting bogged down in implementation code. - the programming language (oz) used to program components has some 30 odd different language concepts and is _more_ that expressive enough for this challenge. The example below is in 'flow-based programming' for the AND logic gate, it is executable: a => a nand(nand) out -> in not(not) out => out b => b nand() The above represents the application's logic graph. the Nand is a component and is implemented in Oz. the Not gate on the other hand looks like this on the inside: The not gate is a composite-component. NOT gate: in => a nand(nand) out => out in => b nand() In the above example the 'in' on the left of the => is the input interface, the out to the right of the => is the output interface. The stuff between the => and => is the logic of the graph. nand(nand) equates to 'name_of_component(type_of_component)'. The second 'nand()' does not need a type as it has already been instantiated. Again the nand gate is implemented in Oz. Now the above representation is very easy to create a high level application logic specific view that is _executable!_ most importantly, the components are being designed so that we may create a GUI: --------- -------- a -----> a| | | | | nand | out -------->in | not | out ---------> out b -----> b| | | | --------- -------- We are currently tying this together with an HTML implementation. So it'll be interactable with a finger. So writing the paper, then implementing it in this interface one creates an executable specification that non-programmers can easily change. This serves as a perfect highly flexible example for implementers to reference for more optimal implementations in say c++ (ie nupic-core). Francisco is this what you imagined? While you're still in town you should come over for dinner so I can demo this to you ;-) >- The “language” of the formal model should allow people from different >(maybe even VERY different) areas to gain full insight into the >fundamental algorithm. >- The formal model should also allow to think, discuss and communicate >concepts at different scales of resolution (from the birds-eye >perspective down to the synapse level) > >I am well aware that this is not an easy thing to do, but I think it is >indispensable for the development of any theoretic research field to >have its own formal notation framework. > >Francisco > >On 15.01.2014, at 07:33, Stewart Mackenzie <[email protected]> wrote: > >> Very good point Jeff, I suspect this material is ready for peer >review (in the idealistic sense of the phrase peer review). I'll admit >I've lost faith in the peer review process of today. For many reasons, >too many to go into at the moment. Though despite my tangible dislike >for journals which needs to be disrupted off the face of the earth, >publishing with them most likely brings more academics onboard. >> >> The main driver for this paper is to get everyone on the same page. >I'd prefer seeing a comprehensive (white) paper, with a series of >smaller papers focusing on smaller areas being published in the >journals. All the detail is in the comprehensive. The smaller papers >are to move academia along using a language and publication process >they are familiar with. I suspect new names should be made to describe >newly discovered phenomenon, with as emphasis on describing the right >'altitude' one needs to approach this problem. This conditions the >academics to start adjusting the mindset to a certain level. Eventually >causing a resonance which hopefully can be conducted into and through >NuPIC. So we as a community had better be sure NuPIC is in shape such >that the resonance won't shatter it. >> >> Jeff Hawkins <[email protected]> wrote: >>> When you say "canonical paper" are you thinking a peer reviewed >paper >>> or an >>> updated white paper? Is it more important to be comprehensive >(white >>> paper) >>> or published in peer reviewed journals? Or are you thinking >something >>> else? >>> Jeff >> >> Kind regards >> Stewart >> >> -- >> Please excuse my typos and brevity >> >> _______________________________________________ >> 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 Kind regards Stewart -- Please excuse my typos and brevity _______________________________________________ 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
