Cooperating Chunks

Confirming and Failing Chunks

This describes the result of my attempts to finally acquire some Chunks. Its all experimantal and Ronnie has implemented another version of them meanwhile. (see Chunk-development)

This describes the result of my attempts to finally acquire some Chunks. Most of the underlying ideas were developed by Joscha and Ronnie and discussed at long Monday evenings in a well known kitchen in Marienburger Str. and in Gantikow. I often write "I" in the following when referring to the implementation that is the objective of this text though since it's me you should blame for anything in connection with this document you want to find somebody to blame for.

Idea

Preamble: If you feel lost in this text it's always a good idea to have a look to either chunk-development or the aep Developer Handbook; this also does have a glossary, so you hopefully find yourself again...

My main interest was in finding a structure capable of fullfilling as many of those requirements we (better say: Joscha) collected over the time, that I can remember (most important of all: beeing suitable for implementing AND,OR,sequences) and beeing minimal in an information theoretic sense while still having meaningfull parts and allowing for a somewhat consistent notation … argh, this is terribly woolly .. so lets make this a little bit more precise: a Chunk should have states corresponding to the different stages of its behaviour, it should have as few Slots and Gates as possible but at the same time it should still be possible to assign meaningfull names to these Slots and Gates; moreover, the Chunks should be designed in such a way that they allow "elegant", what ever that may be, implementations of AND, OR and sequences.

I basicly discarded a whole lot of the Doernerian Quad-architecture idea since (I am affraid) I never really understood the whole philosophy behind that anyway; so, lets say I leave it for other people to clean up behind me as far as these matters are concerned. Never the less the "directions" that Doerner uses (SUB , POR ...) still do appear in my design, since these are still the appropriate terms to describe the topologies we want to build with our nets; it's just that now the various links do no longer come in pairs, going back and forth. But have a closer look yourself …

Internals

A short version of the concepts goes as follows. First of all, Chunks have two different types of links, to communicate with their sisters and brothers (i.e. Chunks having the same parents): one line, inhibit confirm, allows them to deny their neighbours to confirm, the other one, inhibit fail, to disconfirm. Further, Chunks can be inactive, inhibited (then they are not reacting to anything) or doing actual work. In the latter, they first get requested (on a special request line) and then request their children themselfes, but only if certain preconditions are satisfied: if both, inhibit fail and inhibit confirm, have active links then the Chunk delays requesting - which does make perfectly sense for a lazy Chunk, why on earth should it start requesting if it is neither allowed to confirm nor to disconfirm. Requesting Chunks then patiently wait for their children's answer, which will eventually either be "confirm" or "disconfirm" (not much interesting to say these days, them kids) and accordingly get confirmed or disconfirmed (or failed) once this happens. They then (dis)confirm themselfes as soon as their neighbours allow them to do so, i.e. when no incomming inhibit (dis)comfirm link is active any more. Chunks activate their outgoing inhinit (dis)confirm links as long as they are not (dis)confirmed.

And now for something completely different: the details ..

Slots & Gates:

All Gates have corresponding Slots and vice versa. A typical member of our new species Chunks on the surface looks as follows:

Here, the Slots are labeled with the prefix IN, the Gates with the prefix OUT (I know, what a revolutionary idea ...). More specifically each Chunk has the following Slot/Gate pairs:

• SUB_REQ - SUB Request (for requesting a child)
• SUB_INH - SUB Inhibit (for inhibiting a child)
• SUR_CONF - SUR Confirm (for (dis)confirming to a parent)
• POR_CONF - POR Inhibit Confirm (for inhibiting confirmation)
• POR_FAIL - POR Inhibit Fail (for inhibiting disconfirmation)

States:

A Chunk can be in different states:

• Inhibited (Chunk has some incoming activation on SUB_INH)
• Inactive
• Requested (Chunk is requested but not yet requesting itself)
• Requesting(Chunk is requesting its children)
• Confirmed (Chunk is confirmed but does not confirm yet to its parents)
• Failed (Chunk is failed but does not disconfirm yet to its parents)
• Confirming(Chunk is confirming)
• Failing (Chunk is disconfirming)

Depending on its current state, the incomming activation on its different Slots and (!) which Slots/Gates do have incoming/outgoing links the Chunk changes its state. This process is depicted in the following figure:

Here the "important" transitions are colored black; the grey transitions do merely reflect the fact that a Chunk can always change to the state Inhibited or Inactive, if IN_SUB_INH is "turned on" respectively IN_SUB_REQ "turned off".

In more detail, the transition (and output) rules are as follows:

• if IN_SUB_INH > 0 go to Inhibited; from Inhibited go to Inactive as soon as IN_SUB_INH changes to 0 again
• if IN_SUB_REQ = 0 go to Inactive
• go from Inactive to Requested if IN_SUB_REQ > 0; in this case also forward a negative signal of value -IN_SUB_REQ to OUT_POR_CONF and OUT_POR_FAIL
• from Requested go to Requesting and copy the activation from IN_SUB_REQ to OUT_SUB_REQ if not both IN_POR_CONF and IN_POR_FAIL do get negative incoming activation, again, set OUT_POR_CONF and OUT_POR_FAIL to -IN_SUB_REQ
• from Requesting go to Confirmed of IN_SUR_CONF jumps to some positive value and to Failed for a negative value; if there are no OUT_SUB_REQ and IN_SUR_CONF links then we default to Confirmed; further we still send a negative signal to OUT_POR_CONF and OUT_POR_FAIL in this state
• first of all, if both OUT_POR_CONF and OUT_POR_FAIL do have outgoing links, we never go to Confirmed (beginning or middle of a sequence);from Confirmed we go to Confirming either if IN_POR_CONF has no incoming links (and or end of a sequence) or IN_POR_CONF has incoming links and we get non-negative activation on these links (or); then we send +1 to OUT_SUR_CONF and again -IN_SUB_REQ to OUT_POR_CONF and OUT_POR_FAIL; in all other cases, i.e. if we do not change to Confirming, we do not send any activation to OUT_POR_CONF or OUT_POR_FAIL
• the transition from Failed to Failing works analogously (send a -1 to OUT_SUR_CONF); we don't need a "we never confirm if .." rule here though

Logic

Now lets turn to our favourite 3.5 implementation examples for examining how these Chunks work.

SEQ:

A sequence in Chunkish looks like this:

OR:

OR now is different from what we always thought it should be like (see Chunks and Logic). The main reason is that, contrary to former beliefs, the children of an OR need to "communicate" with each other as well: only if all of them fail shall they report this to their parents (alternatively one could get the idea of transfering this decission to the parents (after all its them who should be responsible, shouldn't they ..): a parent fails only if all its children fail; this leads to problems with the sequence and the and though, so we better leave responsibility with the children). So OR turns out quite symmetrical to AND (as we will see); I like this!

AND:

As remarked, we have an AND version, symmetrical to the OR; this is approximately the AND,version1 of Chunks and Logic.

In addition, we can just as well use sequences and a dummy Chunk for implementing the AND,version2 of Chunks and Logic. A picture for this Chunk topology is left as an exercise to the reader.

Examples

You get all these examples discussed above together with some more complex structures with the mlb-file attached to this document ( in these examples there is always a Sensor called "Anschalter": connect this sensor to the data source "1.0" to turn the net on, disconnect it and run the net an appropriate number of steps for resetting it; the sensors "+1", "0" and "-1" can be connected to Chunks as desired for testing the functionality, they are already (dis)connected to datasources as intended; the state transitions can be monitored in the log file; have fun).

For convenience I give a short description of the examples that come with the mlb-file here; I can not but hope that the notation is selfexplanatory.

Notation:

Logic: and, or, seq F: False T: True I: Inhibited comma: set of chunks connected in the same way to other chunks

The examples: (attached as files)

Name	Description
CF_OR.mlb	Kopf( Arm1(F) or Arm2( Finger1(I) and Finger2(F) ) or Arm3(F) )
CF_SEQ.mlb	Kopf( Arm1 seq Arm2( Finger1 seq Finger2 ) seq Arm3(F))
CF_AND.mlb	Kopf( Arm1( Finger0(F) ) and Arm2( Finger1 seq Finger2 ) and Arm3 )
CF_AND2.mlb	Kopf( (Arm1 , Arm2(I) , Arm3) seq Schulter )

Meckerei

There are several details I still don't like about this implementation and others that still need some further thoughts.

First of all, I convinced myself with the interpretation given in the beginning of this text that "inhibit confirm" and "inhibit disconfirm" can together be interpreted as "inhibit request", but I still feel a little uncomfortable with this solutions since in reality these are just different things. Something I really dislike is the "never confirm" if there are outgoing "inhibit confirm" and "inhibit fail" links rule. Here we are only conditioning on the existence of certain outgoing links, we are not even considering their activation; plus: I really didn't find any interpretation that gives all this some meaning here … I mean, apart from the trivial: that we just need it to get sequences working properly.

Joscha also had the Idea of allowing e.g. sequences that work without having a "ruling" and "conquering" parent, by just activating the next Chunk in the chain by its predecessor. I think it should be possible to get this working with the set of states and links given here, but the details still need to be specified.