346 lines
19 KiB
Plaintext
346 lines
19 KiB
Plaintext
Welcome to Gem-graph !
|
|
|
|
Gem-graph lets you move and transform drawn objects using an automaton. It's an
|
|
ideal tool for describing the evolution of a situation through drawing. Would you
|
|
like to see your drawings evolve automatically to represent a phenomenon?
|
|
Gem-graph lets you transform your drawings as you wish. You can draw whatever you
|
|
want. It's your drawing and you decide how it evolves! You can use gem-graph to
|
|
make a game. You can use it to make a model of a phenomenon that interests you.
|
|
You can represent what you want simply or in more realistic detail. You can draw
|
|
in one, two or three dimensions. Simple parts and more detailed parts can coexist
|
|
in the same design. You can watch what you have created evolve without interfering
|
|
or guiding it towards what you want to achieve. You can mix several drawings and
|
|
animations. You can observe them in detail, modify them, go back, start again,
|
|
measure, compare and keep the results that interest you so that you can play them
|
|
again.
|
|
|
|
However, a certain amount of effort will be required to achieve this.
|
|
A complicated model will require more work than a simpler one, but it is possible
|
|
to start with something simple and develop it step by step. In any case, you must
|
|
draw what you want to see and say how you want it to be transformed. Gem-graph
|
|
cannot do that for you. Gem-graph can only help you to draw up and develop your
|
|
idea. However, it can give you powerful tools to do so. The strength of gem-graph
|
|
- short for 'geometric graph' - lies in the fact that it deals only with very
|
|
simple drawing elements, all of which are similar, and that the rules it uses to
|
|
manipulate these elements are equally simple and similar. As a result, these rules
|
|
can be combined and processed automatically, no matter how many there are. The
|
|
tools provided by gem-graph give you access to the power of the automaton it uses
|
|
to draw and animate your drawings, and this manual is here to help you to learn
|
|
how to master them.
|
|
|
|
One way of doing this is to reproduce very simple examples, such as when a
|
|
programming language asks you to write "Hello world". For gem-graph, the
|
|
equivalent of "Hello world" will be to move a small line on your screen. This
|
|
example and other simple ones that follows will progressively give you an approach
|
|
of what gem-graph can do and enable you to build and animate much more complex
|
|
drawings that suit your desires. If you like learning this way, start here (@see 1).
|
|
If you prefer to learn by reading what the commands you see on the screen are
|
|
doing, they have been detailed here (@see 2). The table of contents is another
|
|
way to learn. It goes from the simplest to the most complicated. How to set up a
|
|
simple model (@see 3), observe it and measure what it does (@see 4), then
|
|
transform it by changing what you see and how it reacts (@see 5) or directly deal
|
|
in with the details of gem-graph mechanism itself (@see 6). You may also whish to
|
|
compare gem-graph to other classes of automata that do quite similar things, and
|
|
look at what it can actually do and what its limitations are (@see 7).
|
|
|
|
------------
|
|
|
|
[@ 1] Our "Hello world" is the simplest program that gem-graph can execute. It
|
|
consists of a single short arrow, which moves in a straight line in a single
|
|
direction. To do this, we first had to draw this little arrow (@see 8) and then
|
|
make it move (@see 9). The result is certainly not very exciting, but this example
|
|
is enough to show how a drawing is made and how it is animated. One state and one
|
|
rule are enough. The rule only says: if an arrow is drawn here, I erase it and
|
|
redraw it on the next square. For the moment, you don't need to know in detail
|
|
how the rule works (it's described here: @see 6). Like in all the examples
|
|
demonstrated in this manual, the model is assumed to evolve in a flat space (@see 8).
|
|
All that gem-graph needs to know to execute such models is written in the "Hello
|
|
world" file (@see 10).
|
|
|
|
To improve this model, it is possible to give the arrow the ability to move in
|
|
two directions: forwards or backwards. We can call this second model a "random
|
|
walk" (@see 11). To do this, we need to add a second rule. This second rule says:
|
|
if an arrow is drawn here, I erase it and redraw it on the previous square.
|
|
A random draw (@see 12) is also necessary to determine whether the first or second
|
|
rule applies. With these two rules and the random draw, the arrow now sometimes
|
|
goes forwards, sometimes backwards.
|
|
|
|
The second model (the random walk) had one state (the arrow) and two rules
|
|
(forward/backward). Now here's a model with two states and two rules: the "pendulum"
|
|
(@see 13). This time, the arrow can be drawn either tilted forwards or tilted
|
|
backwards (these are its two possible states) and the two rules switch the drawn
|
|
arrow from one state to the other or vice versa. In the file, the states are here
|
|
(@see 14) and the rules here (@see 15). The pendulum does not change place, but
|
|
alternates between left and right. Like the previous ones, you can slow down the
|
|
programme so that you can observe the movements (@see ~).
|
|
|
|
Once you know how to write a state and a rule, you can write thousands of them:
|
|
they will always be combinations of the same elementary form. However, it is also
|
|
possible to combine programs: for example, you can combine the reports and rules
|
|
from the two previous models to create a new model that shows both phenomena
|
|
simultaneously. Once again, in the file, the states are here (@see 16) and the
|
|
rules here (@see 17).
|
|
|
|
The next example shows how the same rule can be applied to a multitude of states.
|
|
The rule is the same as that used in the second model: an arrow can only be moved
|
|
one square forward or backward, but this time you have to check that this square
|
|
is free. If it isn't, the arrow won't move. Once the rules has been modified in
|
|
this way (@see how), it can be applied to a multitude of arrows distributed
|
|
randomly in space (@see more details here ~).
|
|
When you set the model in motion, you will see all these small lines moving at
|
|
random towards left or right. The same two rules only are responsible for all
|
|
these movements.
|
|
|
|
In the next example, we first build a model similar to the previous one: a
|
|
multitude of arrows are randomly distributed in space, but this time they are
|
|
vertical and the movements are up and down instead of right and left (@see ~).
|
|
Then, we add this model to the previous state and set the final model in motion.
|
|
We see then little lines moving from left to right or reverse if they are
|
|
horizontal, and up and down or reverse if they are vertical. Their number is
|
|
constant. They don't change shape or direction. There seems to be no accident when
|
|
they cross. Nothing else happens.
|
|
|
|
The last example in this series, because it shows a multitude of diverse and
|
|
simultaneous movements, perhaps gives the impression of a more complex system.
|
|
It would be easy to make it even more complex, but it's much more interesting to
|
|
show how gem-graph can be used to analyse and control that complexity. At this
|
|
point, it's time to have a look to the gem-graph mechanism (@see 6) and to compare
|
|
gem-graph to other classes of automata that do quite similar things to better
|
|
understand what it can actually do and what its limitations are (@see 7).
|
|
|
|
------------
|
|
|
|
[@ 8] This is where the heart of the "Hello world" model lies and where it's worth
|
|
starting to learn it. The model consists of a single state and a single rule.
|
|
The state is a 30 x 20 flat space (NB The number of rows and columns are counted
|
|
from zero inclusive. @see 10: line 21). All the examples demonstrated in this
|
|
manual will evolve in the same space. In the "Hello world" model, the arrow is
|
|
initially located in the middle of this space in square (@see 10: the values (14, 9)
|
|
are line 34). After applying the rule, it will have been moved to (15, 9). If the
|
|
same rule were applied again, it would be moved to (16, 9) and so on, always to
|
|
the right (The x coordinates increase from left to right).
|
|
|
|
[@ 9] Note that the rule (@see 10: lines 38-47) does not specify which square in
|
|
the space it should apply to. The automaton guarantees that the rule will apply
|
|
everywhere in space (@see ~). It simply states that if an arrow is at this point,
|
|
it should be moved one square to the right. It is made up of two parts: a condition
|
|
(@see 10 line 39) and a transition. The transition is made of two actions (@see 10
|
|
lines 44-45). The condition says: "If there is an arrow at the address (0,0,0),
|
|
then the rule applies". The address is given by the address of the box (x, y)
|
|
plus the number of the site in this box. There are "sites" in each box of the space.
|
|
Each site harbours the arrows oriented towards a neighbouring cell or itself.
|
|
A weight of 1 indicates that there is an arrow at this address. A weight of 0
|
|
indicates that there is no arrow at this address. The two actions to be performed
|
|
in this case are each described by a line: the first one (@see 10: line 44)
|
|
indicates that the existing arrow at address (0,0,0) should be deleted; the second
|
|
one (@see 10: line 45) indicates that a new arrow should be written to address
|
|
(0,0,1), i.e. the next cell. The rule can be summarizedas follows:
|
|
|
|
<condition x="0" y="0" site="0" weight="1"/>
|
|
|
|
<transition>
|
|
<arrow x="0" y="0" site="0" weight="0"/>
|
|
<arrow x="1" y="0" site="0" weight="1"/>
|
|
</transition>
|
|
|
|
Note that, for this model to be complete, a parameter called "loop_on_space_size_x"
|
|
must be specified. If it is set to: loop_on_space_size_x="true", anything moved
|
|
beyond x_max returns to x_zero space. If it is set to: loop_on_space_size_x="false",
|
|
anything moved beyond x_max is lost. In case of vertical movements, a similar
|
|
loop_on_space_size_y parameter would be required (for a complete space description
|
|
@see ~).
|
|
|
|
------------
|
|
|
|
[@ 11] The "random walk" model consists of one state and two rules. As these two
|
|
rules apply to the same state which is the same as in the "Hello world" model,
|
|
they differ only in their transitions. Again, each transition is made of two actions,
|
|
each described by a line. The first line is identical in both cases. It indicates
|
|
that the existing arrow at address (0,0,0) should be deleted. The second line
|
|
differs: in one case it indicates that a new arrow should be written to address
|
|
(0,0,1), i.e. the next cell, while in the other case it indicates that a new arrow
|
|
should be written to address (0,0,-1), i.e. the previous cell.
|
|
[@ 12] A random draw is necessary to determine whether the first or second rule
|
|
applies. It consists in a probability that is associated to each of them. This
|
|
probability can be set to 0.5 for each or any other value. The sum of all
|
|
probabilities must be 1. You must also indicate that they share the same parent
|
|
condition and have separate identities. The complete writing becomes:
|
|
|
|
<condition x="0" y="0" site="0" weight="1" id="move_west_or_east"/>
|
|
|
|
<transition probability="0.5" parent="move_west_or_east"
|
|
id="move_the_arrow_to_east">
|
|
<arrow x="0" y="0" site="0" weight="0"/>
|
|
<arrow x="1" y="0" site="0" weight="1"/>
|
|
</transition>
|
|
<transition probability="0.5" parent="move_west_or_east"
|
|
id="move_the_arrow_to_west">
|
|
<arrow x="0" y="0" site="0" weight="0"/>
|
|
<arrow x="-1" y="0" site="0" weight="1"/>
|
|
</transition>
|
|
|
|
Initially, the arrow is located in the middle of planar space. Since each of the
|
|
two transitions can be applied with a probability of 0.5, the arrow can be moved
|
|
either towards (15, 9) or towards (13, 9). If the same rule were applied again
|
|
and again, the movement of the arrow would be a random walk with an increasing
|
|
probability of moving away from the starting point in either direction. Once again,
|
|
the rule does not specify which square in space it should apply to. It simply
|
|
states that if an arrow is at this point, it should be moved one square to the
|
|
right or left. Note also that, for this model to be complete, another parameter
|
|
called "loop_on_zero_x" must be specified. If it is set to: loop_on_zero_x="true",
|
|
anything moved beyond zero returns to the maximum space. If it is set to:
|
|
loop_on_zero_x="false", anything moved beyond zero is lost. In this example, each
|
|
transition has an identifier. This makes it easier to manage each rule when there
|
|
are many of them.
|
|
|
|
------------
|
|
|
|
[@ 10] All that gem-graph needs to run the "Hello world" file is detailed in this
|
|
file. The most interesting part concerns the description of the arrow (@see 8
|
|
and line 34) and its movement (@see 9 and lines 44, 45).
|
|
A full Gem-graph XML model includes also information that is not interesting for
|
|
understanding how Gem-graph works. These informations are detailed in the following
|
|
example of a typical gem-graph model file. They include: date (line 8), author
|
|
identity (lines 6, 7), model identity and parameters (lines 5, 10), rules identities
|
|
and parameters, objects definitions, current measurements and results.
|
|
In all the examples demonstrated in this manual, the model is assumed to evolve in
|
|
a flat space of 30 x 20 squares. As the number of rows and columns is counted from
|
|
zero inclusive, this size of space is noted: 29 x 19 (line 21) and its middle 14 x 9.
|
|
The x coordinates increase from left to right; the y coordinates increase from bottom
|
|
to top. To simplify, z values have been omitted. Two parameters named "loop_on_zero_x"
|
|
and "loop_on_space_size_x" can be set to true or false. If loop_on_zero_x="true",
|
|
anything moved before zero reenters at the end of space else it is lost. If
|
|
loop_on_space_size_x="true", anything moved beyond the space size x reenters at
|
|
the zero of space else it is lost (lines 19, 20). These parameters must be defined
|
|
at least for x and (in case) for y and z. Site_multiplicity = number of sites in
|
|
a space unit (line 22). Each site points towards a neighbouring space unit.
|
|
Site 0 points towards the current space unit itself. Several arrows can be stacked
|
|
in the same site.
|
|
|
|
|
|
line 1 <?xml version="1.0" encoding="UTF-8"?>
|
|
line 2 <gem-graph-model version="0.1.0">
|
|
line 3
|
|
line 4 <identity>
|
|
line 5 <name>Hello World</name>
|
|
line 6 <owner>owner</owner>
|
|
line 7 <owner_id>owner_id</owner_id>
|
|
line 8 <date>date</date>
|
|
line 9 <version>1.0</version>
|
|
line 10 <g_ref id="id" date="date" author="author" lang="en">En</g_ref>
|
|
line 11 </identity>
|
|
line 12
|
|
line 13 <parameters id="id" date="0" author="author">
|
|
line 14 <simulation>
|
|
line 15 <max_thread>0</max_thread>
|
|
line 16 <max_cycles>0</max_cycles>
|
|
line 17 </simulation>
|
|
line 18 <space-param>
|
|
line 19 <loop_on_zero_x="true"/>
|
|
line 20 <loop_on_space_size_x="true"/>
|
|
line 21 <dimension x="29" y="19"/>
|
|
line 22 <site_multiplicity="1"/>
|
|
line 23 </space-param>
|
|
line 24 </parameters>
|
|
line 25
|
|
line 26 <objects>
|
|
line 27 <object id="one_arrow" date="date" author="author">
|
|
line 28 <arrow site="0" weight="1" x="0" y="0"/>
|
|
line 29 </object>
|
|
line 30 </objects>
|
|
line 31
|
|
line 32 <savedstates>
|
|
line 33 <state id="initial" date="date" author="author">
|
|
line 34 <arrow site="0" weight="1" x="14" y="9"/>
|
|
line 35 </state>
|
|
line 36 </savedstates>
|
|
line 37
|
|
line 38 <conditions>
|
|
line 39 <condition site="0" weight="1" node_id="1" parent="0" x="0" y="0"/>
|
|
line 40 </conditions>
|
|
line 41
|
|
line 42 <transitions>
|
|
line 43 <transition id="move_one_arrow_to_east" probability="1">
|
|
line 44 <arrow site="0" weight="0" x="0" y="0"/>
|
|
line 45 <arrow site="0" weight="1" x="1" y="0"/>
|
|
line 46 </transition>
|
|
line 47 </transitions>
|
|
line 48
|
|
line 49 </gem-graph-model>
|
|
|
|
------------
|
|
|
|
[@ 13] The "pendulum" model consists of two states and two rules. Suppose the
|
|
pendulum is in the middle square (x="14", y="9") and the states describe an arrow
|
|
as being inclined backwards (site="6") or forwards (site = "7"). Each rule detects
|
|
one of these two positions by means of a condition and modifies the inclination
|
|
of the arrow by means of two actions: one that deletes and the other that rewrites.
|
|
Here again, conditions and transitions are written separately and must be
|
|
identifiable so that they can be linked. Here are the two rules:
|
|
|
|
<condition x="0" y="0" site="6" weight="1" id="inclined_backwards"/>
|
|
<condition x="0" y="0" site="7" weight="1" id="inclined_forwards"/>
|
|
|
|
<transition parent="inclined_backwards" id="incline_forwards">
|
|
<arrow x="0" y="0" site="6" weight="0"/>
|
|
<arrow x="0" y="0" site="7" weight="1"/>
|
|
</transition>
|
|
<transition parent="inclined_forwards" id="incline_backwards">
|
|
<arrow x="0" y="0" site="7" weight="0"/>
|
|
<arrow x="0" y="0" site="6" weight="1"/>
|
|
</transition>
|
|
|
|
The pendulum does not change place. Lorsque nous avons décrit l'espace dans son
|
|
ensemble, nous l'avons placé au milieu (14,9). Pour la règle, il se trouve en (0,0).
|
|
C'est l'automate de gem-graph qui cherche dans tout l'espace s'il y a une case où
|
|
cette règle peut s'appliquer. Lorsqu'il atteint la case (14,9), l'une ou l'autre
|
|
des deux règles s'applique. La probabilité d'application de chaque règle est de
|
|
"1" et n'a pas été indiquée. Comme les deux règles s'appliquent alternativement,
|
|
le pendule oscille. Il serait facile, en utilisant plus d'états et de règles,
|
|
de décrire son mouvement de manière plus fine.
|
|
|
|
------------
|
|
|
|
[@ 6] Details about how the rule works (how the automaton searches everywhere in
|
|
the whole space a place where the rule could apply and how the rules are evaluated)
|
|
This chapter introduces the gem-graph mechanism.
|
|
|
|
------------
|
|
|
|
[@ 7] The main difference between gem-graph models and agent-based models is that
|
|
gem-graph deals with situations, not agents. In a situation where several agents
|
|
are interacting and each agent could apply a different rule, gem-graph considers
|
|
and processes the situation. Not the agents. Whatever the new situation that
|
|
results from his action, his decision-making process will have been simple and
|
|
straightforward. It will therefore be easy to modify and control. And the diversity
|
|
of possible new situations will be far greater than that offered by agent-based models.
|
|
|
|
The comparison between gem-graphs and cellular automata first comes up against a
|
|
question of vocabulary. What is commonly called a 'rule' in one and the other is
|
|
not the same thing. Gem-graphs and cellular automata have the same power: anything
|
|
that can be done by one can be done by the other, but their writing is not the
|
|
same (details of this comparison here).
|
|
|
|
How can gem-graph be used to analyse and control the complexity of what it
|
|
represents and sets in motion? This chapter introduces the gem-graph mechanism.
|
|
|
|
Gem-graph can reproduce the behavior of any cellular automata. Whatever the state
|
|
of the cellular automaton space at a given time (n), this state can be considered
|
|
as a gem-graph state and a rule can be written to transform it into the next state
|
|
(n+1).
|
|
|
|
The difference with the cellular automaton is that this rule is not generated by a
|
|
"micro-rule" applied cell by cell to the entire state (n). This rule must be written
|
|
by hand and its writing requires knowledge of state (n+1).
|
|
|
|
Writing all the rules that describe all the transformations that have occurred
|
|
when a cellular automaton describes a trajectory (a story) is certainly tedious,
|
|
but it is always possible. And the number of possible histories that gem-graph
|
|
rules can describe is limited only by the size of the space and the number of
|
|
symbols it contains.
|
|
|
|
If a set of "micro-rules", each applied cell by cell to the entire state (n) of
|
|
a cellular automaton, can produce all the possible states that the gem-graph can
|
|
describe, the two representations can be considered to be equivalent in power.
|
|
|