PereGaea
Laslo Godel
ACTIONS
There is an entire class of PereGaea's species I did not include in my Rockpile drawing. As we have just seen, the Tree is made up of Components which do not normally move relative to each other except randomly during winds. We could call these Static RAM Objects. We shall now look at Dynamic RAM Objects whose Components do move relative to each other such as the Dynism's Predators and Prey, and later on, the Dynism itself.
We will however concentrate our attention on these three `generic' Dynamic Objects. Whatever shapes the specific species that make them up may actually have, I will represent them in this simple box-and-stick fashion to keep things simple. As you can see, their bodies derive from simple 3D Universals so that I can represent them with simple symbols later on.
Before Dynisms can begin to identify the movements Dynamic Objects can perform, they must first be able to Identify the configurations such objects can assume either during their performance or as a result of it.
The mechanisms the Dynism needs to do this in fact derive from the Object RAM we looked at back in `Vision'. This was essentially a Stimulus Mapper which allowed the Dynism's Visual Processor to Identify Objects from groups of three or more Tonal Stimuli.
A similar Mapper, using the same 8 x 8 grid, does exactly the same with a Dynamic Object's Components. When the Dynism looks at and Identifies a particular Dynamic Object, it immediately transfers all the Object Numbers of its Components from the Object RAM into what we'll call a `Config Map'. This in effect records whatever configuration a Dynamic Object is in either when it is stationary, or while it performs a movement at a particular instant in time. We will look at how it `selects' those instants a little later on.
At this stage the Testers that transfer the Component Numbers into the Config Map are very crude, since they use the same rules as for Object Maps. Larger Components like the Body simply have their Numbers repeated over each of the Cells it subtends, while several smaller ones might occupy a single Cell. This may make Matching such Maps to their corresponding Config Templates unreliable.
Here the Dynism needs to acquire a `Pivot Tester'. After each Component is Identified, this Tester assigns a Cell in the Config MAP to it that depends on where it joins to another. If the Component is part of a leg for instance, the Pivot Tester inserts its Number nearest the point where it joins to the next, or at its end if is a Foot or Claw. The Thorax might be assigned five Cells, four where the four limbs join to it, the fifth where the Head and Neck does.
Of course the Dynamic Object may be visible from any orientation, which means the Dynism will need an entire set of Config Templates for each domain of the Orientational Sphere it surrounds it with.
More advanced Dynisms will instead extend their Config Maps into three dimensions. When such a Dynism encounters a Dynamic Object, its Visual Processor will translate its Orientational Sphere data into Cells within this new Config Map, which will now in effect contain a model of the Object. If the five Thorax Cells are maintained in fixed positions within the Map so that the position of the Body is always fixed relative to it, the Map can then be more easily matched to a single set of Config Templates.
Such `Model Maps' may well be used for other types of Object the Dynism may encounter on Peregaea, for they offer the advantage that the Dynism can if necessary react to Components hidden from view behind larger ones.
Once again a fairly complex perceptual process such as Identifying a Dynamic Object's Configuration Attribute can be broken down into readily processable numbers.
How many Config Templates will a Dynism need to match all of a Dynamic Object's possible configurations? As with all other forms of Template Matching we have seen, the Dynism need not always Identify a particular configuration precisely, a loose match may
often be all that is required.
Configs may also be matched to two separate Templates. A Prey may for instance adopt a particular stance, to brace itself perhaps while it moves its head to various random positions to either drink or to feed. By retaining a Template for the stance `component' of the Configuration only, the Dynism can then `graft' any significant head positions onto it. Similarly with other of its Components such as Claws or even any prehensile Tail.
In addition to this, let's assume that on PereGaea as on Earth, Dynamic Objects can be sorted into classes that share the same basic components. Even though their components may differ considerably in appearance, the members of one such class might, like our three Generic Species, possess a head, a neck, a torso, and four legs. Subclasses are also possible in which one or two components are inserted or deleted, a Proboscis or Abdomen for instance. One single set of Config Templates can therefore serve for all.
Once the particular Dynamic RAM Object is Identified, the Observational Sphere Translator can rescale the lengths of the Components of its `model' in the RAM accordingly or, as we've just seen, add or delete them where necessary. Even though the `configural repertoires' of all species will then be combined in the one set of Templates, the total will still be considerably less than if Config Templates for each were stored separately.
How can Configs be Identified if a Dynamic Object is partly obscured by other objects, Dynamic or Static? Or if it is obscured by other objects identical to it?
In this event the Config Identifier will either fail to match it at all, or nearest-match it to several Templates. In the latter case more advanced Dynisms may select from a choice of two or three Templates at random, we will come back to how such `decisions' might be made later on.
Where the Object is entangled with others identical to it, the way their Components are Config Mapped in effect `joins' them together, so they will usually be associated with the correct Object. It seems unlikely that too many Configs will be Identified in any fast-moving engagement such as a Conflict however. This brings us back at last to Motion and Movement - and we should perhaps at this point distinguish between Motion and Movement on PereGaea. Motion occurs when any object either rotates or translocates within the Dynism's visual field. Movement on the other hand occurs when a dynamic object's components undergo motion with respect to each other.
I make this distinction because on PereGaea the mechanisms for Identifying them are quite different. Radial motion towards or away from the Dynism is of course handled by the Retinal Boxes, motion across the Visual Field by a stimulus-tracking mechanism that derives from the eye-centering reflex we've already seen. Rotational motion is derived from the orientational position of the Thorax.
As you can imagine, extracting and matching a Config for a Dynamic Object that is making a movement is likely to take several of the Standard Time Intervals we saw earlier. How few must these timespans be relative, say, to those required for a Dynism's Predators or Prey to complete the briefest movements in their repertoire?
The Config Identifier need not work so fast that it `freezes' all movement. This is because at certain points in a jointed Dynamic Object's movement, one or more components will momentarily `freeze'.
For instance, a limb Component can only extend so far before it must return, or it may need to halt in a certain position to allow another attached to it to move. Although the periods of time required for such movements may be brief, momentum and inertia prevent them from being infinitesimally small. Several such `Inflexion Points', as we'll call them, may therefore occur if this momentum and inertia causes `rhythms' to build up as a Dynamic Object crawls or walks for instance. The duration of the briefest Inflexion Point therefore fixes the upper limit of the timespan within which the Extractor must extract and Match its Configs. As for the lower limit, it is reasonable to assume there will always be some Objects that can move some of its Components so fast the Dynism won't even be able to extract more than a partial Config. Some Config Templates may evolve to allow for this by leaving out such Components.
Also, when a Dynamic Object is at an Inflexion Point, the temporarily halted components may be in a configuration that is impossible for the Object to adopt under any other circumstance. Just as we can often recognize what an object is doing from a single still photograph, such unique configurations may sometimes be all the Dynism needs to Identify an entire movement.
At this stage the Dynism may evolve the ability to observe a movement for long enough to build up a sequence of Configs into a list of them. We'll assume a minimum of three unless the movement is so brief it can only extract the first and the last. We'll call such a sequence an `Action'; here I've represented each of the Configs making up an Action with symbols contained in circles.
The Dynism attempts to match this Action as it proceeds, Config by Config, to all the Action Templates we'll now assume its ROM contains. Since a Dynism may not begin observing an Action until after it has started, an Action segment may be matched to a Template at any position along its length. These Templates therefore also have `Score Buffers' attached to them. The Action Identifier will increment the scores of those Templates that it continues to map an Action onto as it proceeds or until it completes. The Template with the highest score becomes the match; if there are two or more that share the highest score, one is selected at random.
Although each Template is made up of the minimum number of Config Numbers required to match an Action, some will also end in a Halt Flag so that, once Identified, observation does not continue beyond that point. This is essential for repetitive Actions; those involved in locomotion for example. The Action is actually represented twice in the Template to ensure that it can be Matched from any point in the sequence.
Having looked at Action Identification in broad outline, we can now look briefly at some of the details.
While the Dynism may have to match most Actions to Templates Config by Config to match their Minimum Scores, in some cases it may need only to match certain of their individual Configs to one of a set of alternatives within the Template. Such sets are marked with what we'll call `Parallel Tolerance Flags'.
Similarly with sequential order; portions of an Action Template that do not need to be matched in the same order have Serial Tolerance Flags attached to them.
More advanced Dynisms will also attach a Flag to the point in a Template at which an Action first began to be matched to it. This allows a different response to be selected to an Action according to how far it has progressed.
Dynisms may also come to conserve ROM space by storing Action Templates recursively. In other words, an Action can include another shorter Action which normally has a template of its own. To allow this, all Actions must have Numbers, just as Objects do.
The speed at which a movement is made may often be as important as the Action itself. A mechanism counts the Standard Intervals between the extraction of each Config Number in an Action, then compares it to similarly positioned `normal rate' Interval Numbers within the Action Template it is matched to. The difference between the two can then be used to extract a `Rate Flag'. This may then be used in a Production Rule.
While Actions may be both Transitive and Intransitive, at this stage the Dynism is not able to `link in' those Objects Transitive Actions are performed on or with.
We will now go on to look at Actions the Dynism may itself perform in response to various stimuli, whether these be from Static Objects in its environment, Dynamic Objects, or from other Dynisms.
