155 lines
20 KiB
Plaintext
155 lines
20 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 that interests you? Gem-graph gives you transformation tools that allow you to go from drawing to drawing to describe what you want. Not only is it your design, but you also decide how it evolves! You can use gem-graph to make a game. You can use it to make a model. You can represent what you want simply or in more realistic detail. Simple parts and more detailed parts can coexist in the same design. You can do it in two or three dimensions. You can watch what you've created evolve without intervening, or guide it by modifying your initial rules towards what you want to achieve. You can even mix several drawings and animations. You can observe them in detail, modify them, go back, start again, measure, compare and keep the histories and 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. However, it can give you powerful tools to help you. 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. All the static information is in the space. All the dynamic information is in the rules that transform this space as you want. As all the rules gem-graph uses are equally simple and similar, they 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 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 (_learn_by_example). If you prefer to learn by reading what the commands you see on the screen are doing, they have been detailed here (_learn_commands). 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 (link), observe it and measure what it does (link), then transform it by changing what you see (link) and how it reacts (link) or directly deal in with the details of gem-graph mechanism itself (link). 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 (link).
|
|
|
|
------------
|
|
|
|
[target] 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 (_hello_world_arrow) and then make it move (_hello_world_rule). The result is certainly not very exciting, but this example is enough to show how a gem-graph drawing is made and how it is animated. One rule and one state 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 can skip the details about how the rule works (_gem_graph_mechanism). The model is assumed to evolve in a small flat space which is described here (_hello_world_space). All that gem-graph needs to know to execute such models is written in the "Hello world" file (_hello_world_file). How to execute this example is explained here (_hello_world_exec). You can now detail this first example (_hello_world) or continue reading to have a first approach of what the next models will show you.
|
|
|
|
From this first model, it is possible to give the arrow the possibility of moving in two directions: forwards or backwards, and to ensure that these movements occur randomly. This second model therefore describes a "random walk" (link). 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 (link). A random draw (link) 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" (link). This time, the arrow can be drawn either tilted forwards or tilted backwards and the two rules switch the drawn arrow from one state to the other or vice versa. In the file, the states are here (link) and the rules here (link). The pendulum does not change places. It only moves from left to right and vice versa. You can slow down the programme to observe the movements better (link).
|
|
|
|
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 add models together: for example, you can combine the states and rules from the two previous models to create a new model that shows both phenomena simultaneously (link). This is easy because the two models are independent, but if a rule in one applied to a state in the other, it would be up to you to change it. Gem-graph can't do this for you, but it can detect such situations and provide you with tools that automate or at least facilitate the merging of the two models (link).
|
|
|
|
The next example shows how the same rules can be applied to a multitude of states. The rules are the same as those used in the second model: an arrow can be moved randomly one square forwards or backwards, but this time there can be arrows anywhere. You must therefore always check that the square where the arrow could go is free. If not, the arrow will not be moved. Once the rules has been modified in this way (link), it can be applied to a multitude of arrows distributed randomly in space (link). 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.
|
|
|
|
Using the previous example, it's easy to create a model where the arrows are vertical and move randomly from bottom to top or top to bottom (link). If we add this model to the previous one, we see little lines moving randomly from left to right or vice versa if they are horizontal, and from top to bottom or vice versa 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 (link). As these two models are independent, they were immediately added together without any additional operations.
|
|
|
|
This last example, 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 the value of gem-graph is how it can be used to analyse and control that complexity. At this point, it's time to have a look to the gem-graph mechanism (link) and theory (link) 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 (link).
|
|
|
|
------------
|
|
|
|
[@ 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" date="date" author="author">
|
|
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.
|
|
|