Representing conflicting states in the Workspace

One of the characteristics of Copycat is the ability to pursue alternate or conflicting views of its domain, although in a limited way only. When Codelets build up structures (groupings of and relations between entities) in the Workspace these structures go through “states,” from possible over proposed to established. There can be only one set of established, non-conflicting structures.

For example with three entities A, B and C, Copycat might first create the group G1={A, B}. Another sequence of Codelets might build up the conflicting (because each entity can only be direct member of one group) group G2={A, B, C}. In order to establish G2 the group G1 has to be torn down, but G2 can coexist with G1 as long as it is in proposed state.

This way Copycat can explore alternatives that conflict with the current view, but might turn out to be better. But the conflicting structures have to compete at a very low level. In the simple case above can easily measure that group G2 is superior to G1 and thus decide to tear down G1 in favor of G2. But in more complicated scenarios an alternative group G2' could seem less promising at first, but once it has been constructed it opens the possibility for a very complex structure which could not be built with G1. This makes Copycat kind of shortsighted, i.e. the presence of G1 suppresses groups which are scored lower than G1 if compared directly to it, but might act as a first part of a more complex structure.

Tabletop seems to have the ability to remember structures and when it explores an alternative that turns out to be a dead end, it can go back to the remembered structure. This way it can be more open to alternatives than Copycat. But I don’t know how this was implemented in Tabletop, because I have not yet read anything more detailed about it.

Last night, while lying in bed waiting for the sandman to come around, my brain was spinning around this and looking for ways to improve the situation. One possible option could be the introduction of “Branches” in the Workspace, which would be a generalization of the “snapshot” feature that Tabletop seems to have. Each Branch is a Workspace in the Copycat sense, but now the Workspace can contain multiple “sub Workspaces.” Each time a Codelet wants to establish a conflicting structure in a Branch, this Branch is forked and the alternative can be explored without interfering with the existing Branch. Now Branches would compete against each other instead of lower level structures. Each Branch gets a score and if one Branch falls behind too much, it is discarded.

There a various ways how this could be implemented. All Branches could be active at any time, which means that the processing capacity has to be shared by all Branches. This makes branching very expensive, so a mechanism that limits the number of Branches is required. The expected value of a proposed structure has to greater than a threshold value before it can be established – this is a mechanism that already exists in Copycat as it is now. If the structure now conflicts with other structures, a penalty is added to this value which is based on the number of existing branches, so it become very unlikely that a new Branch is created when already many Branches exist.

Another option would be to have only one Branch active at a time and every once in a while the system decides if it should switch to another Branch. Or it might shard its attention to all Branches based on the Branch’s scores, with a very large skew towards the highest score – but still leaving some attention to lower scored Branches.

Just an idea…