PereGaea

Laslo Godel

5: ACTIONS

There is an entire class of PereGaea's species entirely missing from the 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.

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. The mechanisms the Dynism needs to do this evolve from the Branch Testers we saw in the previous chapter. Such Testers map the relative positions of a Dynamic Object's joints into what we'll call a `Config Map' using a 5 x 5 grid. These joints are themselves Objects, in this case `knees' and `ankles' assembled from the sets of Areals and Lineals from the pairs of Components making up each. Hip joints are not needed since their positions are fixed by the main Component of a Dynamic Object, its Thorax.

The Thorax is recorded in the center square of each Config Map, along with the Orientation Flags derived from the Orientational Sphere it surrounds it with. The Dynism will need an entire set of Config Templates for each of this Sphere's domains.

More advanced Dynisms will evolve a more advanced Tester that is in effect a `Translator' that converts all the data in a Config Map into a three dimensional Model Map made up of cubic cells. This new kind of Map in effect contains a `model' of the Dynamic Object. The Thorax is represented by four fixed cells, each now representing its hip joints. The map is orientation independant, it is exactly the same even if the Object it models is upside down. The Map can then be more quickly matched to a single set of Config Templates.

How many Model Templates will a Dynism need to match all of a Dynamic Object's potentially huge number of configurations? Not all that many if its joints have limited ranges of movement, and if a Dynamic Object does not need to adopt more than a relatively limited range of configurations.

Flags can also be added to a Model to indicate the positions of minor components where necessary; a Prey may for instance adopt a particular stance while it moves its head to various positions to drink or feed.

Let's assume 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. One single set of Model Templates may therefore serve for all.

How can a Dynism identify a Dynamic Object's configuration if is partly obscured by other objects, Dynamic or Static? It can do so if it can match its visible joints to a single Model Template, otherwise it can only identify the Object itself.

Where the Object is entangled with others identical to it, the way their Components are Config Mapped in effect seperates them; they will usually be associated with the correct Object. It seems unlikely however that many of their configurations will be Identified.

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. We've already seen the mechanisms it uses for identifying rotation and translocation, we will now look at those it now evolves for identifying movement.

As you can imagine, extracting and matching a Model Map for a Dynamic Object that is making a movement has to be done very quickly indeed. But just how quickly relative to the time it takes for a Dynism's Predators or Prey to complete the briefest movements in their repertoires?

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 Dynism must extract and Match its Models. 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 Models 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 Models making up an Action with symbols contained in circles.

The Dynism attempts to match this Action as it proceeds, Model by Model, 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 Flags' 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 Model 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 Model Templates one by one to match their Minimum Scores, in some cases it may need only to match certain of their individual Models 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 Flags within the Action Template it is matched to. The difference between the two can then be used to extract a `Rate Flag'. The Dynism can then use it to select the most appropriate Response.

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.