Fixing AttemptExtension December 12, 2006
Posted by amahabal in Uncategorized.2 comments
One of the actions suggested by a group— when it is the current thought— is to schedule an AttemptExtension codelet. I will describe how this works, and then argue that it needs fixing.
Here is how the thing currently works. Let the sequence under consideration be “1 7 8 2 8 9 10 3 9 10 11 12…”, and let us assume that the group ‘8 9′ has been seen, and that this is the group on which the codelet has been let loose. The codelet needs an extra argument telling it which direction to extend in: left or right. We will try to expand right.
The codelet first figures out what the next object in that direction should be. In this case, the next object would be a 10. In step two, it checks whether this is the object present in the workspace at that location. In this case, it is. In step three, it handles the logistics like actually adding the object to the group, updating relations and so forth.
All these steps look fine and behave well in the sequence we were considering. Can you guess where we are going to run into trouble? As a hint, a troublesome sequence is ‘1 2 2 3 1 2 3 3 4 1 2 3 4 4 5…’
Yes, step two is the culprit. In the sequence ‘1 2 2 3 1 2 3 3 4 1 2 3 4 4 5…’, Let us try to extend the marked group right. Step one tells us to look for a ‘3′. Step two does the looking, and finds the 3. Except, for this sequence, that is the wrong 3. The program needs to see the [3 3] as a 3 in order to see the sequence as “really just 1 2 3 1 2 3 4 1 2 3 4 5…”. Since step 2 is so literal about what it seeks it cannot find the right answer. (And this is a vindication of my use of fringes. The program does solve this problem via a different route involving fringes. But that is a story for another day).
The literalness of the second step currently makes it impossible for the program to see the sequence “1 2 0 4 5 1 2 3 0 5 6…”. Here, even the fringes cannot help: the fringe of 0 certainly does not contain ‘4′.
What we need from step two is a check that an object of the sort we seek is present in the workspace at the particular location. In our troublesome example, we need an object that can be seen as a 3. Both ‘3′ and ‘3 3′ fit the bill. However, this raises a timing issue: what if the ‘3 3′ had not yet been seen as a group? Or if it had not been seen as possibly standing for a 3? There is an additional complication involving time. In the sequence “1 2 0 4 5 1 2 3 0 5 6…” there is understandable resistance to seeing the 0 as a 4. This resistance is overcome as more examples of similar squinting are noticed in other parts of the sequence. Similarity space, thus, changes its shape over time. What was dissimilar can become similar, and vice versa.
The new approach— yet to be implemented— replaces the second step with something more elaborate:
- Get all adjacent objects in the redirection of the extension. In the troublesome example, that includes the 3 and (if it has been seen as a group,) ‘3 3′.
-
For each such object, the question “can this object be seen as a 3″ can have three possible answers:
- “yes”
- “Hmm, never thought about this. I need to think”
- “no, I tried it, does not work”
- If we get (c) as an answer for all objects, the extension cannot be done, at least for now.
- If we get (a) as the answer for more than one, we can pick one.
- For any (b)s, we should launch codelets exploring the likelihood of that squinting. Subsequent attempts can use what the codeless discover.
Finally, we must add another codelet that shakes boundaries. What it should do, for a given group, is to shorten and then elongate the group at one end. This is like treating the boundaries as somewhat tentative and fluid. Pragmatically, this is our insurance against choosing wrongly if several possible answers look valid while extending. No choice is binding. Moreover, this also makes groups a more fluid data structure. I will end with a short quote from page 119 of FCCA:
Thought’s fluidity emanates from the non-rigidity— the fluidity— of representational structures. They have an ability to adjust, to alter themselves effortlessly, to assume many conformations. For fluidity to emerge at a high level in a computer model of thought, the underlying data structures must be permeated by an ability to flip back and forth at the drop of a hat [...]
A change of terminology: no more relations December 12, 2006
Posted by amahabal in Uncategorized.add a comment
In the post “relations” I described how the relations Seqsee notices have both related objects sharing a category, and also mentioned exceptions in the world around us: George W. Bush and the United States do not share obvious categories, and yet, the question “how is Bush related to the United States?” is not inane and has an answer.
I want to step back and point out that the relations Seqsee needs most are really descriptions of change—”how can I change a ‘1 2 3′ to a ‘2 3 4′?”—and being able to apply the same change to other objects. Applying the same change to ‘5 6 7′ yields ‘6 7 8′. I want to suggest changing relations to change descriptions.
Unfortunately, this term sounds mechanical and lifeless. Relations is a warm word, deriving part of its warmth from human relations. Lifeless or not, I think change descriptions is more accurate. Seqsee gets its traction from descriptions, and this is true at several levels. Descriptions drive similarity discovery, for example.
Am I, with this shift in nomenclature, outlawing relations not based on shared categories? Are there not aspects of the domain that are genuinely such relations? The relation between a ‘1 2 3′ group and the category ascending, for example?
No, these live on, as they always have, in long-term memory. Long-term memory is a graph (of the nodes and edges variety), and can be a home for arbitrary associations between ideas. All I am suggesting here is renaming a concept to be more accurate.