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
