OMo program

Note: One of the most convenient ways to run the program on a non-DOS machine is via vDos, an application that sets up its own DOS environment on your computer. All you have to do is pair a DOS drive letter with a Windows drive/directory letter, copy the program into it and type its name in the DOS window.

The program can be downloaded. Please read the manual!

1. Why the OMo program
Essentially OMo is a way to show how the computer model can be linked to an environment for a certain purpose. In this case it means having to move from one point in space to another.

The focus is on demonstrating the linkage and its effects. OMo is not meant to be an exercise in computer graphics nor does it have a sophisticated user interface. The underlying computer model has a more useful interface because it is designed to be experimented with without the need for recompiling the code with every change in the parameter Menus.

Apart from illustrating the effects OMo is meant for programmers for whom recompiling the code throughout the testing is not a problem, especially since any further application would require inserting OMo's code into an already existing program anyway. It helps therefore if any peripherals are kept to a minimum so that the actual system doing the work can be identified as clearly and unambiguously as possible. It also helps that the code is in C/C++ running as a DOS program (with graphics) so that hardly any changes are necessary to transport it into whatever programming environment. Both programs have been compiled on Borland C++ Version 4.0 under Windows.

If you happen to be a CG animator the question is, what is the point with OMo?

Suppose you have a figure meant to move from one point to the next, and suppose the environment would dictate a certain type of movement. For example, the figure could carry a heavy load, hence different movements of its limbs; or, it walks through water, hence an influence by this medium; or, it is buffeted by wind, again this has an effect on the movements.

The conventional way is to attach a submodule that provides the input to the figure in order to simulate the environment. Another method is to let a human perform the action and reference points on the arms, legs etc are monitored so that their movements can be transposed into the CG scenario. Either way there is an outside input, that is a rule set separate from the figure which 'tells' the figure what to do.

What if there is a system that steers the figure in the first place, and which processes any additional information coming from say, the environment so that the figure adjusts its dynamics right there and then - with as many in- and outputs as are necessary under the circumstances? Maybe for a CG animator such a need is not really significant, but if you want to run a robot the issue does become important. After all, you wouldn't want some 'template' running alongside your robot all the time telling it what to do every single moment - the robot should act autonomously. And a CG animation functioning along these lines could be more realistic.

And so to OMo.

2. History
OMo stands for Otoom Movement, and Otoom is the acronym for "On the origin of Mind", the text containing the entire explanation behind the mind model.

A shorter explanation focusing on the artificial mind aspect only and hence the computer simulation, can be found in the paper "How the mind works: the principle dynamics in the bio and non-bio version", published at the IPSI-2005 Venice conference in November 2005 (here referred to as the paper). The computer simulation will be referred to as OtoomCM (Otoom Computer Model).

To understand the idea behind OMo reading this page is enough.

To fully understand the principles behind OtoomCM a reading of the paper is advisable. It is not necessary to read Otoom, although it would be required to understand the wider scope relating to the human mind and society at large.

OMo is an exercise in applying the system of OtoomCM to a certain purpose.

It can be freely experimented with provided acknowledgment is made to the author and the material behind it. No responsibility is taken for the running of the program or the behaviour of the code on any machine or platform.

3. Summary explanation of the computer model
The OtoomCM seeks to simulate the biological brain as much as possible.

The configuration consists of a matrix where every point is a node, and each node is another matrix consisting of elements which are integers spread across in a series. The first matrix is called the main matrix, the matrices at each node are called element matrices. The rows and columns constituting the rim of the main matrix are reserved for in- and output, where each set of in- and output nodes can be split into a number of in- and output regions, one each for a certain type of in- and output. The in- and output nodes are connected to the nodes inside the matrix, and these nodes are referred to as the inner matrix. The inner matrix is the processor of the system, where its nodes are connected to each other in the form of virtual trees with various levels of branchings resulting in a considerable overlap of nodes belonging to separate trees. A processing algorithm is applied from every node to its dependants with the result that the respective integer values are modified in terms of stable, periodic, or strange attractors (this means that under continuous application by the algorithm an integer either converges towards its counterpart, begins to oscillate at a certain frequency, or moves about in an erratic fashion).

The nodes in the main matrix stand for the neurons in the brain, the in- and output regions for the brain's receptor areas of sensory organs and/or the broadcasters of its output to limbs and organs, the trees for the connections between the neurons, the elements in the element matrices for the protein formations inside the neurons, and the integer values produced by the algorithm simulate the neurotransmitters at the synapses (the connections between each of the neurons).

Applying some input to the main matrix causes the element matrices to enter certain phase states, which in turn form clusters in terms of such states. These clusters can stabilise and so perform the function of memory through their re-representative quality regarding the input, become re-representative abstracts of the input, they can be modified by ongoing input, or they can be split or diminished altogether.

Think of those clusters as idea complexes, that is specific clusters of states representative of some input. The size of the numbers in each element is not the issue - what is significant is their relationships with the numbers in other element matrices, in other words their dynamic affinity relationships established by the algorithm against the functional background of connectivity and scale.

Note: the OtoomCM is not another type of what are called artificial neural networks!

4. Summary explanation of the OMo model
In the OMo program the matrix system has been extracted from the OtoomCM in order to facilitate the application of separate in- and outputs.

The program can be run in two essential versions (a parameter in the code can be used as a switch).

In the simple version all the in- and output nodes comprise one respective region, and the input is applied to that one input region, gets processed within the inner matrix and the output is taken from the one output region.

In the other version there are several in- and output regions (currently the maximum is three, but that can be changed easily in the code - just follow the comments). For example, input region #1 receives the coordinate values of a point in space, input region #2 gets some other data, output region #1 supplies the updated coordinate values for the next point location and the output from region #2 is thrown away. Or, input region #1 receives the other data, input region #2 gets the coordinate values, output region #1 supplies the coordinate data for the next point location, and the output from region #2 is thrown away.

Make up any other combination as you wish, especially with more regions, and apply the data from any kind of process to some input region and send the output from some output region to anything else in addition to the point location recipient.

As can be seen (particularly with a greater number of nodes, more elements, a higher connectivity, and bigger trees), the developing clusters of states (see above) tend to separate the data respective of the in- and outputs. How useful the produced values prove to be in the end depends on the nature of the inputs and how the outputs can be applied to the overall purpose. This is where the experimentation comes in!

A word of caution: start with the Menus as per the test runs below. If any kind of combination of main matrix rows and columns with any number of element rows and columns and connectivity is chosen the program may crash, because this simplified version of the OtoomCM does not feature the internal checks of its more sophisticated counterpart (as I said, this is for programmers). Use common sense.

As said before, in OMo the idea is to move from one point in space to another. The space is indicated by the x-y-z axis, where each side is of equal length and represents 100 units. The z axis (depth) is simulated in a rudimentary fashion, but the points drawn on the screen are adjusted according to their z value (for example, they get larger as they move towards the front).

To provide a more accurate picture of the changing x-y-z values separate graphs are shown in the three blue boxes above the green space coordinates (see the accompanying jpg files). The bottom line of each graph represents the movement steps from start point to end point. Each step here is one pixel, and if the number of incremental steps is larger than the pixels making up that line a ratio is used. The left side of each graph represents the values for each coordinate, the full height standing for the 100 units of the sides belonging to the space. As each coordinate value moves away from the initial starting value at each step the current value is shown advancing horizontally. The values belonging to the direct movement from start to end are shown in white, the values resulting with Otoom contributing are shown in red. The two can be compared through the 2D-rendering inside the green axes or separately in terms of the x, y, and z value.

The parameters given via the text on the screen are, from top to bottom -
main matrix rows to element matrix cols - self explanatory;
number of connections/node - the parameter in the code refers to the connectivity as a percentage value (ie, 10% means that if there are 100 nodes then each node is connected to 10 other nodes); on the screen the percentage is converted into actual numbers;
connection depth - how many branchings there are on each tree (ie, if four nodes are connected to every node and the connection depth = 3, then the first node [level 0] is linked to four other nodes [level 1], each one of these nodes is connected to four other nodes [level 2], and each one of those other nodes is again connected to four other nodes [level 3]);
seed times - before the processing of actual values begins, setting this parameter to 0 means providing input to the system with the output thrown away;
seed value - the input from above;
number of input (output) regions - into how many regions the in/output nodes are divided into (see above for details);
alternative input - the input value which is apart from any other input provided through the location point calculations;
in- output region selected - that's the region which receives/supplies the in- and output relating to the coordinate values;
block factor - if 0, the algorithm is applied only once throughout the matrix; if >0, determines how many more times it is applied to the main matrix nodes;
Changed region mode! (etc... in red) - pops up if the coordinate values and the alternative input are changed around (see above for the details);
incremental steps - the increments the path between the start and end points is divided into;
waypoints - the x-y-z values as the point is drawn along the way with the updated values (these values are the 2D-transposed values for the green coordinate space);
start (end) point - the x-y-z coordinate values of the points related to the green axes space.

All of the above parameters can be changed, keeping in mind the caution about memory usage mentioned before. Therefore, after completing a test run the screen can be saved and the image file used for later reference.

I have tried to keep the functional context of moving from one waypoint to the next as far away from the system as possible. Since this is a simulation only, there is always the issue of having somehow determined from the outside what the next step should be, in a sense the exact opposite to the intent of the program. However, consider that in a 'real' environment some other input does in fact represent a modifying influence - the question becomes, will such an influence be effective enough. The efficacy of this other input depends on what the input represents (that is, from what process it is derived), and what the system is able to do with it. The latter item is subject to the internal processing by the system, and its influence is determined by the relationship between it and any other input. It all comes back to the affinity clusters mentioned earlier. They do exist, as can be demonstrated in the OtoomCM, but how they will interact with the clusters representing the output under focus is a matter for experimentation. Currently the other input is the 'alternative input', a rather primitive version. On the other hand, other inputs can be provided which are as complex and meaningful as one can make them. The greater the scale of such an arrangement the more interesting the result.

5. Some test runs and their results
The results of the test runs are captured as screenshots in jpg files.

OMo01-01.jpg:
Simple setup with one in- and output region. Change in x coordinate values with Otoom almost identical to those without Otoom (the red spots cover the white ones completely), except for the last step. Y-values mostly asynchronous, z-values similar to x. Note: the last step under Otoom has not been achieved because the program stopped before reaching values that go beyond the end point. It is possible to take smaller and smaller steps towards the end, but that would be an overloading of rules which may or may not be justified under certain circumstances, but not in this test I feel. This goes for all the test runs.

OMo01-04a.jpg and OMo01-04b.jpg:
Switching the in- and outputs over, so that in *b.jpg the alternative input plays a role in determining the waypoints and the outputs from the location values are thrown away. But no difference in the results.

OMo01-07a.jpg and OMo01-07c.jpg:
An effect similar to the *6* series can be seen in terms of changing the in- and outputs with the regions between *a.jpg and *b.jpg (a slight difference in the progress by the z values), and again a difference in the z values once the connectivity had been scaled down in *c.jpg.

OMo01-08a.jpg and OMo01-08b.jpg:
A larger configuration and therefore a higher probability of separate domains for in- and outputs forming. In *a.jpg there is slow convergence for the x and y values, and the z values are accelerating towards the rear. However, eventually the system produces output which seems to compensate for the initial disparities. The x, y, and z coordinate values for the last steps before the test run was halted were,
68-18-212
66-17-215
65-17-208
65-16-201
64-16-204
62-15-195
59-13-194
59-13-186
57-12-182
55-11-178
55-10-179
54-9-163

In this setup the output contributes to the waypoint location but a component of the input is the incremental distance between the start and end points. Even with this simplistic guidance towards the goal (whatever that may be) it appears the system is capable of learning, given the later trends towards convergence.

On the other hand, in *b.jpg the matrix configuration is smaller (less nodes connected and only 2 depth levels). There is a convergence towards the end point, particularly with the z values after going the wrong way at first. However, the convergence is more erratic than with *a.jpg, and from test runs on OtoomCM it appears that erratic behaviour is usually associated with small domains (small clusters of nodes having similar phase states).

The screenshots from the test runs are available in the OMo program file under Downloads. Here is one example.

Overall -
- feeding the data through the Otoom system is not just another substitute for different figures, but has a specific influence on the progression of values;
- the values are not as smooth as a more direct reference to the intended path would provide, and the degree of 'less smoothness' can change along the way;
- although the number of increments between the start and end points was fixed, it served only as some guide without inviting too many indeterminables into the test scenario, but they do help illustrate the rate of progress;
- there is no intentionality in the test runs, but this feature would be a composite of relatively complex feedback circuits which convey the idea of 'this and not that' within the context of the situation (as it does in real life);
- the facility exists to expose the system to as many inputs as desired, with a corresponding number of outputs that can be used for some type of feedback;
- more extensive configurations with a greater number of in- and output regions and some other, more sophisticated ways to develop input should confirm at what scale of setup the system becomes capable of learning (that is to say, affinitive domains come into being which contribute to the character of other associated domains currently in progress);
- a text file facility can be added so that during a test run the waypoint coordinates and their time stamps can be saved for later (this helps to evaluate the rate of convergence or otherwise);
- many experiments are waiting!

© Martin Wurzinger - see Terms of Use