gem-graph-client/docs/rtfm/gem-graph.texi

\input texinfo 
@c https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.pdf

@c @paragraphindent 0

@c @fonttextsize 10 (instead of 11) enable to see the intro in one page.

@c from: Appendix B Tips and Hints p 242:

@c "Write in the present tense, not in the past or the future."
@c "Write actively! For example, write “We recommend that . . .”
@c                         rather than “It is recommended that . . . ”.
@c "Use 70 or 72 as your fill column. Longer lines are hard to read."  <<<
@c "Include a copyright notice and copying permissions."
@c "Design your manual so that it can be read sequentially, as far as possible."

@setfilename gem-graph.texinfo
@settitle Gem-Graph manual
@copying
Copyright @copyright{} 2024 Jean 'jean' Sirmai
@sp 1

@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts.  A copy of the license is included in the section entitled
``GNU Free Documentation License''.
@end quotation
@end copying

@defindex au
@defindex gl

@titlepage
@title Gem-Graph Manual 1.0
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@contents
@node Root
@c (version @value{VERSION}, @value{UPDATED}).
@node Introduction
@chapter Introduction
@cindex Introduction

Welcome to Gem-graph!
@sp 1
@glindex Automaton
Gem-graph lets you move and transform drawn objects using an automaton.
It's a tool for describing the evolution of situations through drawing.
It allows you to conceive and apply rules that create new drawings from
the previous ones. Your design is no longer frozen: you can decide how you
want it to evolve! You can use gem-graph to make a game. You can use it to
tell a story. You can use it to make a model of a phenomenon that interests
you. You can represent any scene simply or in more realistic detail.
Simple parts and more detailed parts can coexist in the same design and
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. Finally, you can observe them in detail and modify them and go
back and start again and measure or compare and keep the sequences and
other results that interest you so that you can play them again.
@sp 1
@glindex Gem-graph principles
@glindex Gem-graph design
@glindex Gem-graph rules
@glindex Gem-graph drawings
However, a certain amount of effort will be required to achieve this.
A complex model will require more work than a simpler one, but it is
possible to start with something quite simple and develop it step by step.
In any case, you have to draw what you want to see and say how you want it
to be transformed. Gem-graph cannot do that for you. However, it does
provide powerful tools to help you. Gem-graph - short for 'geometric graph' -
is a redrawing system. Its strength lies in the fact that it deals only
with very simple drawing elements, all of which are similar. All the static
information - your initial drawing - is an arrangement of these elements
in space. All the dynamic information - your redrawing rules - transform
what you draw as you wish. All gem-graph rules, whatever their complexity,
are only associations of an unique simple pattern: one condition on one
element of the drawing triggers one action on the same element.
Due to this very simple structure, any set of complex rules, no matter
how many there are, can always be processed automatically by the gem-graph
automaton. The tools provided by gem-graph give you access to this power
to create and animate your drawings, and this manual is here to help you
learn how to master them.
@sp 1
@glindex Hello world
@glindex Gem-graph by example
@anchor {intro_very_simple_examples} Reproducing very simple examples,
such as when a programming language asks you to write "Hello world",
is one way of learning. 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 follow 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
@pxref {node_gem_graph_by_example,, Hello world, Gem-graph by example}.
@sp 0
If you prefer to learn by reading what the commands you see on the screen
are doing, they have been detailed in the
@ref {gem_graph_commands,, commands, Gem-graph commands}.
@sp 0
The table of contents is another way to learn. It goes from the simplest
to the most advanced topics: How to set up a simple model, observe it,
measure what it does and display the results, then transform it by changing
what you see and how it reacts. You can directly deal in with the details
of gem-graph mechanism itself. You may also whish to compare gem-graph to
other classes of automata that do quite similar things and examine what
it can and cannot actually do and what its scope of application is.
@sp 0
Finally, you might like to get a taste of the theory behind it all
straight away.
In short: there exists a minimal form for geometric graphs rewriting.
There is no simpler way of drawing than to combine several occurrences
of the same symbol in a space made up of a single type of spatial unit.
This deep simplicity makes the strength of gem-graph.
@sp 0
George Boole once established the bases of the simplest algebra.
Explore now a path to the simplest geometry by rewriting geometric graphs!

@node gem_graph_by_example
@chapter Gem-graph by example
@cindex Gem-graph by example
@cindex Automaton
@glindex Gem-graph by example

@section Hello world
@cindex Hello world
@glindex Hello world
@anchor {hello_world} 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 and
then make it move. 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 ignore how
the automaton works (the details are in _gem_graph_mechanism).
The model is assumed to evolve in a small flat space which is described here
(_hello_world_space). All gem-graph needs to know to execute such model is
written in the "Hello world" file (_hello_world_file). Note that all gem_graph
models will have basically the same structure, making them easy to copy and
share. How to execute this example is explained here (_hello_world_exec).
To go back to the Introduction:
@ref {intro_very_simple_examples, ???, Reproducing simple examples}
@sp 1
@section Random walk
@cindex Random walk
@glindex Random walk
@anchor {random_walk} 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". To do this, we need to add a second rule which only says: if an
arrow is drawn here, I erase it and redraw it on the previous square. It is then
necessary to determine randomly whether the first or second rule applies. With
these two rules and this random choice, the arrow now sometimes advances and
sometimes retreats. The detailed description is here: (_random_walk).
@sp 1
@section Multiple random walks
@cindex Random walks (multiple)
@glindex Random walks (multiple)
@anchor {multiple_random_walks} The next example shows how these two rules can
be applied to several states. To test this, we start by populating the space by
randomly distributing in it a large number of arrows, all with the same
orientation.
We now need to adapt our rules by checking that the square where an arrow can go
is free. If not, the arrow will not be moved. Once the rules have been modified
in this way, they can be applied to any arrow in the space. When you set the
model in motion, you will see all these small lines moving at random towards
left or right (_horizontal_random_walks). This shows that the gem-graph
automaton is constantly exploring the whole space to see where the rules you
designed can be applied.
@sp 0
By adapting this example, it's easy to create another model where the arrows
are vertical and move randomly from bottom to top or top to bottom
(_vertical_random_walks).
@sp 1
@section Pendulum
@cindex Pendulum
@glindex Pendulum
@glindex Pendulum synchronization
@anchor {pendulum} In the previous random walk models all  states were similar
(one arrow) even if there were many of them and there were only two rules
(forward/backward). Now here's a model with two states and two rules:
the "pendulum" (_pendulum). 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. The pendulum location does not change.
It only moves from left to right and vice versa. You can slow down the program
to observe the movements better (_gem_graph_commands). It could be a good
starting point to draw a complete clock or a solar system.
@sp 1
@section Models addition
@cindex Models addition
@glindex Models addition
@glindex Random walks plus pendulum model
@glindex Pendulum model plus random walks
@anchor {random_walks_plus_pendulum}
An amazing feature of gem-graph is that it is possible to add the three
previous models and make them work together (_random_walks_plus_pendulum).
Their addition is immediate because these three models are @strong {independent}.
If they were not, i.e. if a rule in one applied to a state in another,
you would have to change it or slightly modify one of the states.
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
operation (_gem_graph_addition).
@sp 1
Once the addition automatically operated, you can see little lines moving
simultaneously and at random 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. The pendulum is here also, who continues to come and
go, oblivious to all the commotion.
Nothing else happens (_random_walks_plus_pendulum).
Although the system is constantly changing, something always seems to remain
the same (@strong {ergodicity}, ergodic_hypothesis).
@sp 1
@glindex Clocks synchronization model
@glindex Modelling clocks synchronization
@glindex Causal relations modelling
@glindex Modelling causal relations
We could have drawn several independent clocks but they would have be
asynchronous. This is because the automaton randomly selects the targets to
which it applies the rules. It is quite possible to synchronize these clocks
by establishing between them drawn links able to transmit proper signals.
This way of doing has a cost but it enables you to let some events independent
while you can control @strong {causal relations} on some others (_randomization).
@sp 1
@sp 1
@section Addressing complexity
@cindex Complexity
@glindex Complex systems models
@glindex Modelling complex systems
This resulting model, 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, by trying to represent, for example, the
traffic of a city in all its diversity, a video game or the metabolism of a
cell,  but the value of the gem-graph is the way in which it can be used to
analyse and @strong {control} this complexity.
@sp 0
It is the profound simplicity of the gem-graph automaton that allows it to
embrace such a wide range of situations and behaviours simultaneously.
(link > Canonical form)
At this point, it's time to take a look at the mechanism (_gem_graph_mechanism)
and theory (_gem_graph_theory) of gem-graph and compare gem-graph to other
classes of automata that do similar things to understand what its scope is
(_spatial_automata_classification).

@node gem_graph_commands
@chapter Gem-graph Commands
@cindex Commands
@glindex Gem-graph commands
@glindex Commands
@anchor {commands} Gem-graph opens with an overview that lets you see at a glance
the current state of your model, the rules at your disposal and some measurement
results if you have selected any.
@ref {intro_very_simple_examples, ???, back to Introduction}
@sp 1
A panel contains all the commands you need to see how the model behaves in
motion: run/stop, slow down/speed up, step by step, do/undo/redo.
@sp 1
Another group of controls - the 'camera' panel - lets you rotate or zoom in your
model to view it from the best angle.
@sp 1
Gem-graph opens in "run" mode. The only other mode available is "edit" mode.
These two modes are incompatible: you can either run the model or edit it, but
not both at the same time. The command for switching from one state to the other
is at the top left of the title bar.
@sp 1
Other more specific commands can only appear if you have first defined objects
or situations that are of particular interest to you in your model. You can then
colour them in or change their relative transparency so that you can see them
clearly.
@sp 1
From the overview panel, you can move to the state, rules, measurements or
results panels. Only one of these panels/screens is visible at a time. The
buttons that allow you to move from one to the other are in the left-hand title
bar, just next to the exec/edit button, which is furthest to the left.
@sp 1
Some commands enable you to check the performances of the model and of the
automaton and to tune some parameters that could improve them.
@sp 1

@section State panel
@cindex State panel
@glindex Gem-graph Run mode/Edit mode
@glindex Run mode/Edit mode
@anchor {state_panel} The state panel shows you the space where your model
evolves. Run mode/edit mode.

@section Rules panel
@cindex Rules panel
@glindex Rules panel
@anchor {rules_panel} The rules panel is a combination of two panels: one devoted
to the rules tree, the other to a rule you may have selected to study or modify.
As it is often useful to switch from one view to the other, it's nice to have one
next to the other and to be able to enlarge either one easily.
@sp 1

@section Open / Close / Save
@cindex Open / Close / Save
@glindex Open / Close / Save
@glindex Gem-graph Open / Close / Save
@glindex Open / Close / Save
@anchor {Open/Close/Save} Open / Close / Save

@sp 1
@section Help
@cindex Help
@glindex Gem-graph Help
@glindex Help
@anchor {help} Help

@node gem_graph_simple_models
@chapter Simple models
@cindex Simple models
@glindex Simple models
@anchor {simple_model} The aim of this chapter is to make it easier to learn
gem-graph by working in more detail on very simple models.
@sp 1
It is very easy to complicate a model. Sometimes all you need to do is add an
object or a rule and the complexity increases exponentially.
@section Hello world
@section Random walk
@section Multiple random walks
@section Pendulum
@section Models addition
@sp 1

@node gem_graph_mechanism
@chapter Gem-graph mechanism
@cindex Gem-graph mechanism
@cindex Automaton
@glindex Gem-graph mechanism
@anchor {mechanism} 
Le moteur du serveur de gem-graph (scheduler + workers + reference arrows list)
peut exécuter le même type de calcul dans des espaces de toutes dimensions,
toutes tailles, toutes topologies, qu'ils soient bornés ou non (en toutes
directions ou en partie). Chaque concepteur de modèle devrait avoir la
possibilité de définir selon ses besoins chacun de ces paramètres,
indépendamment, pour chaque modèle.
To produce the desired representation efficiently, each set of rules must
satisfy a number of constraints.
@node random_generation
@section Random generation
@cindex Random generation
@glindex Random generation in gem-graph
@anchor {randomization_usage}
@subsection Rules
Génération de règles aléatoires
@subsection States
Génération de dessins aléatoires
@subsection Filtering
Selection tools (filters, pattern recognition)

@sp 1
@section Comparison
A single rule could encompass all the possible
states of the whole space and say, in each case how it must be redrawn.
This rule would be very complex but, hopefully, this theoretical case is
only useful for the presentation of the gem-graph mechanism and comparisons
with other spatial automata.
@sp 0
In practice, rather than writing such a very complex rule, it is possible to
break it down and write a set of small rules, each one indicating how the
state of a small part of the whole space should be transformed (and the graph
representing it rewritten).
@sp 0
As similar situations may recur from time to time here and there, the size
of the set of small rules will be smaller than that of the large rule that
would describe everything.
At this point, before going any further, we need to agree on vocabulary and
definitions.
@sp 0
In gem-graph, a state is a state of the space.
the big rule, the small rules, the global space and the local spaces.
The Big Rule describes all possible rewritings in the Global Space. There is
only One Big Rule and it can rewrite all the possible states of the Global
Space. In contrast, there are lots of small rules and lots of local spaces
and each small rule applies exactly to a local situation in a local space.
@sp 0
Now, how does the automaton works? It permanently searches here and there
in the Global space if there is a situation that can be rewritten. If it
founds one, it rewrites it and that's all. This means that all the local
spaces are independent. Rewritings are parallell and occur at random.
@sp 0
Can a cause and an effect be described in such a representation? Absolutely
yes. A situation A is the cause of a situation B if no other situation can
be transformed (rewritten) in B. If another situation can be transformed
(rewritten) as B, it is another cause of B.
@sp 0
Each small rule is a part of the Big Rule.
Each local space is a part of the Big Space.
@sp 0
@sp 0

that would describe all the possible states of the whole space and say,
for each one, how it should be rewritten

@node gem_graph_space
@section Space
@cindex Space
@anchor {space}
@glindex Gem-graph space
@glindex Space
Espace vide, espace saturé, graphes connexes, objets, percolation

@node gem_graph_rules
@section Rules
@cindex Rules
@anchor {rules}
@glindex Gem-graph rules
@glindex Rules
Non contradiction, non redondance, complétude (théoriquement possible).
Profondeur et largeur de l'arbre des conditions. Parcours d'arbre. Performances.
Détection des règles inutilisées.
Détection des objets ou situations non intentionnelement générés.

@node choice_of_a_space_work_at_random
@section Random
@cindex Randomization
@anchor {randomization}
@glindex Randomization
Le choix de l'espace de travail (espace local) est toujours aléatoire.
Deux situations ne peuvent être synchronisées que si elles sont reliées
(dans l'espace, par le dessin).
Pour représenter le lien entre une cause (état 1) et un effet (état 2),
il faut et il suffit qu'aucune règle n'atteigne l'état 2 sans provenir
de l'état 1. Plusieurs causes peuvent avoir le même effet.

@node ergodic_hypothesis
@section Ergodic hypothesis
@glindex Ergodic hypothesis
Assume that the average of a process parameter over
time and the average over the statistical ensemble are the same.
If an ergodic equilibrium is attained, all accessible microstates are
equiprobable over a long period of time.
Some gem-graph models may satisfy the ergodic hypothesis.
@auindex Boltzmann Ludwig

@node Markov_chain
@section Markov chain
@auindex Markov Andrey Andreyevich
@glindex Gem-graph theory
@glindex Theory
A Markov chain is a sequence of possible events in which
the probability of each event depends only on the state attained in the previous
event. All gem-graph processes are Markov chains.

@node gem_graph_models_addition
@section Models addition
@cindex Models addition
@glindex Gem-graph addition
@glindex Models addition
@glindex Addition of models
@anchor {models_addition} Trois conditions doivent être réunies pour pouvoir
additionner des modèles :
@itemize
@item Ils doivent être dessinés dans des espaces de même dimension.
Il serait possible de copier des objets 2D dans un espace 3D mais
l'inverse supposerait une opération et le plus souvent une perte d'information.
Dans tous les cas, les règles devraient être réécrites.
@itemize
@item  Une unité d'espace d'un modèle (un 'grain') peut représenter des objets de
taille très différente. Pour pouvoir additionner deux modèles, il faut que les
objets décrits soient de même taille dans les deux modèles. Deux familles de
solutions sont possibles :
@item  modifier la taille des objets de l'un des modèle ou des deux, au prix
éventuel d'une perte de définition du modèle résultant.
@item  encourager la production de modèles compatibles dès leur conception
lorsqu'une 'unité naturelle' (ex: atome, individu,...) peut servir d'unité
de représentation et pourrait faire l'objet d'un consensus.
Les outils d'addition des modèles seraient améliorés par la définition préalable
de ces standards.
@end itemize
@item Ils doivent être indépendants. Les modèles indépendants peuvent être
additionnés automatiquement. @anchor {models_independence} Def indépendance:
No rule in one is applied to a state in another.
Le client gem-graph devrait fournir des outils (analyse et possibilités d'action)
facilitant l'addition de modèles interdépendants (merge).
@end itemize

@node gem_graph_labels
@section Labels
@cindex Labels
@anchor {labels} (cf. @url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/17})
@cindex Transitions format
@glindex Gem-graph labels
@glindex Labels
@anchor {transitions_format}
Un graphe géométrique peut être interprété comme un objet (graphe connexe), une
situation (objets proches les uns des autres) ou un 'label' (ou balise).
Un label est un objet (graphe connexe) particulier qui a l'apparence d'une
chaine de caractères (lisibles par un humain ou non) et qui peut être le
support d'une information de nature différente d'un dessin. Un nombre non
prédéfini de labels peut être associé à toute partie d'un dessin lorsque
le concepteur d'un modèle souhaite y ajouter des informations d'intérêt
(valeur, référence, lien, identifiant, addresse, annotation, commentaire, date,
auteur,...).
Il est essentiel que ces informations soient écrites dans l'état et non dans
les transitions car le maintien de l'homogéneité du format d'écriture des
transitions garantit qu'elles peuvent être traitées automatiquement.
Le client gem-graph devrait fournir des outils facilitant l'édition de labels.
Définir des normes faciliterait l'édition de labels.

@node gem_graph_meta_objects_and_transitions
@section Meta-objects Meta-transitions
@cindex Meta-objects
@cindex Meta-transitions
@cindex Vectorial representation
@cindex Pattern recognition
@glindex Vectorial representation
@glindex Pattern recognition
@glindex Meta-objects Meta-transitions
@anchor {meta_object}
@anchor {meta_transition}
@anchor {représentation_vectorielle}
@anchor {pattern recognition}
(cf. @url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/15})
(cf. @url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/14})
Le concepteur d'un modèle peut souhaiter représenter (dessiner) un même
'objet-réel' de différentes façons selon les situations ou suivant les
transitions qui s'appliquent à cet objet. Il peut donc considérer plusieurs
'objets-dessinés' (graphes connexes) comme des représentations d'un même
'objet-réel'. Il peut souhaiter également éditer des liens entre ces différents
représentations et, éventuellement, y ajouter d'autres informations. L'ensemble
des informations concernant un même 'objet-réel' constitue un meta-objet.
Le client gem-graph devrait fournir des outils facilitant l'édition de meta-objets.
La représentation vectorielle, partielle ou complète, des objets devrait être
encouragée lorsqu'elle est possible.
A la date de création de cette issue (nov 2021), cette technique n'a jamais
été testée.

Le concepteur d'un modèle peut souhaiter représenter (dessiner) un même
'objet-réel' de différentes façons selon les situations ou suivant les
transitions qui s'appliquent à cet objet. L'ensemble des informations
concernant un même 'objet-réel' constitue un meta-objet. Le concepteur
peut souhaiter définir une même transition sur tout ou partie des objets
(graphes connexes) d'un ou de plusieurs meta-objet(s). Un ensemble des
transitions concernant un même 'objet-réel' ou meta-objet constitue une
meta-transition.
Le client gem-graph devrait fournir des outils facilitant l'édition de
meta-transitions.
L'utilisation d'outils utilisant des représentations vectorielles des
meta-objets devrait être encouragée lorsqu'elle est possible.
L'identification d'objets et de situations par un ensemble de conditions
est une technique de 'pattern recognition' qui pourrait être optimisée
par des méthodes développées en IA.
A la date de création de cette issue (nov 2021), cette technique n'a jamais
été testée.

@node gem_graph_coupling_to_flows
@section Models coupling to flows
@cindex Models coupling to flows
@glindex Gem-graph coupling to flows
@glindex Coupling to flows
@anchor {models_coupling_to_flows}
(cf. @url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/19})
Certains phénomènes participant à des phénomènes complexes sont décrits
de façon optimale par des équations continues représentant des flux.
Ces modèles utilisent des gradients de variables intensives (ex: pression,
température, densité,...) pour décrire les états et calculer leurs évolutions.
Chaque modèle gem-graph devrait pouvoir être couplé à de tels modèles.
L'idée d'un couplage entre modèles de nature différente a déjà été proposée (ref 1).
Ce couplage suppose remplies au moins toutes les conditions suivantes:
-   superposition des espaces et des temps des deux modèles
-   lecture des valeurs d'une variable d'intérêt du modèle continu par le
modèle gem-graph au moyen d'une condition spécifique
-   écriture dans le modèle continu des modifications effectuées par le
modèle gem-graph au moyen d'une action ('assignment') spécifique.
A cette date (nov 2024), cette technique n'a jamais été testée.

@auindex Wishart, D. S.
@auindex Smith, A.
References
@cite {Smith, A., P. Turney, et al. (2002). JohnnyVon: self-replicating
automata in continuous two-dimensional space. NRC Publications Archive.}
@cite {Wishart, D. S., R. Yang, et al. (2005). Dynamic cellular automata:
an alternative approach to cellular simulation. In Silico Biol 5(2): 139-161.}

@node gem_graph_coupling_to_waves
@section Models coupling to waves
@cindex Models coupling to waves
@glindex Gem-graph coupling to waves
@glindex Coupling to waves
@anchor {models_coupling_to_waves}
(cf. @url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/18})
Certains phénomènes participant à des phénomènes complexes sont décrits de façon
optimale par des équations continues représentant des ondes.

Chaque modèle gem-graph devrait pouvoir être couplé à de tels modèles.

Ce couplage suppose remplies toutes les conditions suivantes:

    superposition des espaces et des temps des deux modèles
    lecture des valeurs d'une variable d'intérêt du modèle décrivant les ondes
    par le modèle gem-graph au moyen de conditions spécifiques prenant en
    compte l'orientation, la section efficace, l'énergie, la phase,...
    écriture dans le modèle continu des modifications effectuées par le modèle
    gem-graph au moyen d'une action ('assignment') spécifique
A cette date (nov 2024), cette technique n'a jamais été testée.

@node non_geometric_graphs_extraction
@section Non geometric graphs extraction
@cindex Non geometric graphs extraction
@glindex Non geometric graphs extraction
(cf. @url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/12})
Des graphes non géométriques pourraient être 'extraits' de chaque état d'un
gem-graph. Ces graphes s'intéresseraient seulement aux propriétés non
géométriques des gem-graphs, oubliant les propriétés liées à leurs coordonnées
spatiales.
Il pourrait être utile de les comparer, de les classer et d'étudier leurs
propriétés mathématiques.
Le client gem-graph devrait fournir - sous forme de modules - des outils
d'extraction de tels graphes à partir de gem-graphs. Des dessins
(sans graphe associé) pourraient être 'extraits' de chaque état d'un gem-graph.
Les annotations, qui ne représentent pas les objets eux-mêmes ni les situations,
seraient alors supprimées ou converties.

@node gem_graph_modularity
@section Modularity
@cindex Modularity
@glindex Gem-graph modularity
@glindex Modularity
@anchor {modularity}
(cf. @url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/13})
Des interfaces gem-graph spécialisées devraient être créés pour traiter les
modèles de certains systèmes complexes particuliers. Liste (non exhaustive)
de communautés d'utilisateurs potentiels:
        biologie cellulaire,
        biologie du développement,
        écologie,
        géographie,
        climatologie,
        économie,
        urbanisme,
        ...
Une organisation modulaire du logiciel permettrait de développer séparément
les interfaces dédiées à des utilisateurs particuliers (ex: accès à certaines
banques de données, références, contexte,...) qui présenteraient peu d'intérêt
pou les autres.
Une bibliothèque de modules spécialisés devrait être organisée.

@node gem_graph_theory
@chapter Gem-graph Theory
@cindex Gem-graph theory
@cindex Automaton
@glindex Gem-graph theory
@glindex Theory
@glindex Philosophy
@section Philosophy
Gem-graph is a tool for representing complex phenomena that are difficult to
present with commonly used tools.
A philosophy of science, art and games is associated to its conception and
developpment. Here it is.
@sp 0
@subsection How to represent?
We can first agree that no complete representation of the world or of what
you imagine is possible. In any case, you have to make compromises and
choices (cf. Luis Borges).
If you are designing a game or creating a piece of art, you need to choose
some degree of realism or abstraction or some materials or tools or media but
not others, etc. If you are a scientist, you have to choose some hypotheses.
Making these choices, you accept some constraints and expect some benefits.
What are the constraints provided by gem-graph? What kind of work and efforts
does it needs? What benefits can it provide?
While looking for answers to these questions, let's try to analyse the
limits that algebraic notations encounter when complexity increases.
Note that all the discussion that follows concerns mostly condensed matter
evolving within Newtonian time and space.
@sp 0
To calculate, you first have to represent. What representations are most
often used and why?
@sp 0
Most physical phenomena can be described by equations in which the objects
are represented by letters and the operations on them by special symbols:
the operators. Chemistry uses several languages ranging from algebra to
geometry. Biology makes great use of images and the natural sciences, in
their broadest sense, cannot escape the use of images. This extends to most
human sciences and practices (history, geography, engineering, etc.).
When is it better to use algebra alone or geometry or both?
How to represent is a choice.
@sp 0
@subsection Symbols shapes and functions
The shape of objects determines their function. It's because the wheel is
circular that it can roll. In the abstract algebraic notations, this relation
from the structure to the function is lost. Most often, the symbol shape says
nothing about the symbol meaning. It may be a mnemonic device, but it is of
no use for calculation.
@sp 0
By contrast, only the shapes of the objects themselves or their reciprocal
positions determines what rule the gem-graph automaton will apply.
Combinations of symbols only - all of one and the same nature - draw these
shapes and the shapes determine the actions.
The more different shapes and interactions there are, the more varied and
complex the model, and the more this representation simplifies the
calculations.
@sp 0
@subsection Writing complexity
The use of algebraic notation means that each of the different properties
of a structure (mass, load, movement, geometry) must be represented by a
different symbols. These symbols may be themselves combinations of simpler
symbols.
When the diversity of objects and interactions is low and good approximations
are possible, this notation simplifies the representation and efficiently
supports the calculations. As the size and complexity of the system increases,
so does the number of symbols involved and the complexity of the writing.
Writing complexity becomes then an independent problem in its own right.
@sp 0
Gem-graph is designed to optimise the description of these situations by
using graphic combinations of a single symbol. Everything that depends on
shapes (fermions) is described by drawings of the shapes. The calculations
are performed directly on the shapes themselves.
As shapes cannot describe the interactions of bosons, a parallel
representation is needed to represent them.
Gem-graph can also interact with parallel continuous representation of the
intensive values of thermodynamic models.
@sp 0
@subsection Naming objects
By associating a symbol with the identity of an object or a class of objects,
we are making the assumption that the identity of this or these objects will
not vary. Describing the changes made to objects named in this way will then
require the introduction of new symbols.
@sp 0
The shapes represented by gem-graph can themselves vary or shift.
The recombinations, deletions or additions of the single symbol used to draw
everything can describe any change to any object without the need to introduce
a new type of symbol.
As for the names of the objects themselves, if they exist, they are not used
by the gem-graphic mechanism.
They can be applied by the model designer to any shape or situations he wishes
to identify a posteriori, for example for measurement purposes.
This possibility is totally independent of the calculation itself.
@sp 0
@subsection Labelling objects
Another possibility is to add @emph {labels} to some objects  or situations.
These labels can be drawned in the space model itself.
A label is a particular shape drawned in the model space.
This shape does not represent a part of the world.
Instead, it encodes a name or a link the conceptor whishes to add towards
some external information. Its moves and/or changes have to be specified by
particular rules.
Ideally, it should occupy as little space as possible so as not to interfere
with the dynamics of the world represented.
As gem-graph is based on the association of integers to each space unit,
it is easy to create numerous labels occupying each a minimal volume and
easy to edit. A network of beacons can therefore be discreetly inserted
into the world design to make it easier to observe.
@sp 0
@subsection Granularity
In a complex system, a great variety of objects must be represented in the
same time and space with the sames scales but not all their parts need to be
detailed with the same precision. Identifying which parts need to be detailed
from those that needs not requires a supplementary treatment. Even if the
final result is a reduction of the total quantity of information no simple
compression algorithm applies to all cases.
@sp 0
Gem-graph requires no additional treatment as its drawings are conceived to
combine areas where the design is detailed with areas where it is not,
simultaneously and  in the same space.
Its rules structure applies in all cases.
@sp 1
@subsection For each model, there exists a simplest set of assumptions
To make evolve representations, sets of rules must satisfy constraints
(non self-contradiction, non redundancy).
@sp 0
Because they must take theses constraints into account, graph rewriting systems
provide a guide for expressing the simplest set of assumptions underlying
each model.
@sp 0
For each model, there exists a simplest set of assumptions.
Can we demonstrate this proposition or its opposite?
@sp 0
@subsection Writing an automaton @c Good practices for ...
In some automaton, states and rules may not be clearly separated and/or may
each be written in an inhomogeneous way.
Each inhomogeneity requires specific treatments and adds its own compexity
to that of the model.
A good practice would be to simplify as much as possible the writing of the
automaton.
@sp 0
The use of a single symbol guarantees both states and rules perfect
homogeneity.
@sp 0
@subsection From continuous to discrete values
Continuous algebraic values must be converted in discrete values to be used
in model simulation.
@sp 0
Gem-graph uses only discrete values. No such conversion is needed.
@sp 1
@subsection Canonical form
There exists a minimal form for geometric graphs rewriting.
@sp 0
No simplest form can exist that combinations of ONE symbol in a space made of
ONE type of space units (to demonstrate).
@sp 0
ref George B. < He spoke about algebra.
It is about geometry now.
@sp 1
@subsection From description to explanation
From the scientific point of view, the explanation differs from description
because it makes an hypothesis on what "stands under" the description.
It necessarily introduces "something" (some structure and/or interaction)
that is not in the description and which causes at least a part of what
is described. Each description is unique whereas an hypothesis may apply
to several descriptions.
@subsection Summary @c redondant  (à déplacer et regrouper)
In brief, gem-graph allows you to represent and make evolve representations
of complex systems whatever the variey of their components and of their
interactions. This power has a price. The initial static representation may
be not too heavy to produce but writing the detailed rules that will specify
the behavior of each possible interaction will be a heavy task.
Gem-graph makes this work possible and facilitates it as much as possible
because its conception allows (1) a progressive approach of the final design
and (2) automatic edition tools of the final product: the initial state and
the rules set that makes it evolve.
@sp 0
Graph rewriting systems are well suited to represent complex systems
(i.e. whith a great variey of components and interactions) and to describe
their evolution because the objects - or rather the situations - are drawn
instead of being forever predefined and associated to a symbol.
The operators are the rules that modify these drawings.
An automaton applies these rules to these drawings which are then "re-drawn".
As all the drawings are made of combinations of a single symbol (an arrow
going from a space unit to another), all the rules that redraw them rely on
the same simple pattern.
Objects are not pre-defined. You can identify them in your initial design but
they can diseappear an you can identify new ones at your convenience.
Gem-graph automaton work is independent of these interpretations.
You can also choose the level of detail you need in any part of your description
and you can associate differents levels and make them evolve at your convenience.
@sp 1

@node spatial_automata_classification
@section Spatial automata classification
@cindex Spatial automata classification
@glindex Spatial automata classification
Spatial automata classification. Scope, definitions
@sp 1
Cellular automata
Artificial chemistries
Agent-based models

@node gem_graph_history
@section History
@cindex History
@glindex Gem-graph history
@glindex History
@anchor {history}
The development of modelling by rewriting geometric graphs has been,
remains and will remain an unfinished process.
May knowledge of its history help to optimise its rewritings!
@sp 1
@glindex Gem-graph invention context
In the 1950s-1970s, a new frontier of knowledge was emerging: nobody
knew how to use the power of computers to better understand biology.
None of the calculation methods known and used until then were really
suitable. A community known as "Artificial Life", led by MIT in particular,
gradually took shape around this issue. Several annual international
conferences bring together biologists, chemists, computer scientists,
roboticists, mathematicians and philosophers. Their exchanges call into
question the boundaries and nature of their different disciplines.
Concepts and even words often mean different things to different people.
In the end, their most solid points of reference were the questions they
share: Can life be defined? Did it appear suddenly or gradually? Is it
necessarily complex? Is a theory of biology possible, or can biology only
be studied and described in its historical context? The "in silico" biology,
a term coined by analogy with "in vivo" and "in vitro", became commonly
used to designate the modelling of living organisms carried out by computer
(whose chips are made of silicon). This term is a misnomer because the
models that use it only reproduce, at best, an isolated property of living
organisms. The problem stemed from both insufficient knowledge and a lack
of methods, in both biology and computer science. Between 1980 and 2000,
the development of computer languages and the power of personal computers
encouraged research using digital modelling. In biology, in 1995, the first
genome was completely sequenced (_ref), quickly followed by others. This
legitimised research into minimal organisms that would be completely known
and therefore controllable (Craig Venter). In 2012, the first complete
model simulating both the metabolism and reproduction of a contemporary
living organism was published (Jonhatan Karr), ushering in the era of
integrative biology.
@sp 0
@url {https://en.wikipedia.org/wiki/History_of_artificial_life}
@sp 0
@url {https://en.wikipedia.org/wiki/Modelling_biological_systems}
@sp 1
@cindex Complex systems
@anchor {complex_systems}
@glindex Gem-graph summarized
@glindex Gem-graph principles
@glindex Gem-graph fundamentals
@glindex Complex systems
In that context Jean Sirmai, author of this manual, invented
gem-graph, seeking to create a spatial automaton suitable for representing
the complex phenomena that take place within a cell. The representation of
the cell was the main focus of his work, and the automaton was seen as
a simple tool. It was difficult to separate the development of the two.
The first model he produced using this technique was published in 2012 (_ref).
Gem-graph was briefly described in it but it already possessed all its
main characteristics and its logical coherence (see Appendix A).

Such as it was, it provided an independent working method that could be
applied to many complex systems, both biological and non-biological.
A complex system was defined here as composed of a large number of
different  objects interacting in a large number of different ways.
From this point on, gem-graph started to become an independent project.


@sp 1
@glindex Gem-graph invention
This invention took place in successive slabeles between 1992 and 2015.
I was not aware of Francisco Varela work when I started my own research.
In 1974, Francisco Varela's tried to represent the autopoietic phenomenon
in a minimal cell in activity. The result of their very first attempt was
a cellular automaton capable of rewriting simple symbols - letters,
operators - in a small flat space. Depending on their relative positions,
these symbols could be transformed and/or moved. A string of 'M's could,
for example, represent a membrane and a '*' a catalyst (ref).
These representations were inspired by John H. Conway's 'Game of Life',
which was frequently studied at the time. (ref)

Both Jean Sirmai's (1992) and
What is different ?
- unique symbol
- the space is explored according to its content
- each transition can convert more than a single cell
- clear separation between space and rules + no other information
- transitions are parallell, independent from each other and occur at random.

Chrystopher L. Nehaniv demonstrated in 2002 that asynchronous cellular automata
can fully emulate the behavior of any synchronous cellular automaton.

Cellular automata has drawbacks. (1) Each transformation applies only to one
cell. (2) The shape of each rule is different, which makes it difficult to
associate them. (3) The history written by this succession of transformations
is unpredictable. An ergodic state can be attained only by chance.
Let's detail these drawbacks and see how gem-graph has solved them.
@c @image {showcase/aXoris minimal cell.png}
@sp 1
@auindex Nehaniv, C. L.
@cite {Nehaniv, C. L. (2002). Evolution in Asynchronous Cellular Automata.
In Artificial Life VIII (pp. 65-73)}

@glindex Cellular automata
@glindex Integrative bio
logy
@glindex Artificial Life
@glindex Biology "in silico"
@glindex Biology minimal organisms
@glindex Biology completude
@glindex Biology theory
@glindex Biology integrative
@glindex Digital modelling
@glindex Biology genome
@glindex Genome sequencing
@glindex Automaton space
@glindex Automaton rule
@glindex Automaton mechanism



------------------

@cite {Karr Jonathan R. A whole-cell computational model predicts phenotype
from genotype Cell. 2012 Jul 20;150(2):389-401. doi: 10.1016/j.cell.2012.05.044.}

@auindex Karr Jonathan R.
@auindex Venter Craig
@auindex Prigogine Ilya
@sp 0
Trois paradigmes: Prigogine Ilya, Varela Francisco, Conway John Horton Le 'jeu
de la vie'

Bottom-up/top-down Analyse/synthèse topics/methods
Modèles minimaux Exhaustivité Complétude (Karr 2012)
Systèmes complexes (dont la bio.)

@auindex McMullin Barry
@cite {McMullin Barry Thirty years of computational autopoiesis: a review
Artif Life. 2004 Summer;10(3):277-95. doi: 10.1162/1064546041255548}

@auindex Varela Francisco
@auindex Maturana Humberto
1974 Le concept d'autopoièse (Francisco Varela & Humberto Maturana) (ref)
Redéfinition de l'autopoièse : persistance + liaison entre constituant d'un
même individu
Isoperformance (relation complexité / efficience de tous les composants d'un
individu)
@auindex Langton Christopher
'Life as it is' versus 'Life as it could be'
@auindex Conway John Horton
Le 'jeu de la vie': un système formel Turing-complet
Le paradigme des automates cellulaires (ref)
Les modèles orientés-objets insuffisants face aux phénomènes complexes (ref)

De 1992 à 2020, réorganisation quasi permanente du logiciel
(structures de données, nommage et algorithmes) (ref) pour résoudre les
contraintes suivantes:
granularité / tailles des structures en interaction
simultaneité / asynchronie

1994 Premier poster à Heidelberg. Critiques: 'pas réaliste'.
Quelle granularité et quelle définition choisir ?
Conclusion : les structures représentées doivent déterminer les fonctions.
Rien de plus. Toute l'information nécessaire à la reconnaissance de la fonction
doit se trouver dans l'état.
1995 premier génome complet (Haemophilus influenzae 400 gènes seulement mais
parasite) (ref)
la connaissance de l'intégralité des génomes ouvre l'ère de l'exhaustivité:
Le nombre de parties d'un être vivant est fini.
Toutes sont ou peuvent être connues et totalement décrites (atome par atome)
Comment reconstituer le tout à partir des parties ?
La recherche d'une théorie biologique et le développement des modèles
(Artificial Life)
Peut-on définir la vie ? Comment ? Le débat naturalisme / vitalisme.
L'exobiologie
Les modèles 'set of keys' and 'bag of chemicals'. Conséquences sur le
"milieu intérieur".
Un arbre logique du vivant distinct du graphe historique.
Postulat: la représentation optimale des connaissances biologiques nomologiques
(non-historiques) ?
Postulat: l'auto-production condition nécessaire de l'auto-re-production.
Une proposition de démonstration : si une structure était dédiée à la
reproduction mais non auto-productrice d'elle-même, c'est une *autre* structure
qui devrait la reproduire.
Ceci conduirait à une récurrence infinie donc impossible.
Une chimie des symboles : Gem-graph peut convertir des états en règles de
transition et des règles de transition en états.

Principales innovations successives:

Transitions locales (pas globales) (à la différence des automates cellulaires)
Initialement, tous les objets de l'espace global étaient des symboles
(des caractères 'M' ou 'E', par exemple) identifiés chacun individuellement
par le programme qui opérait leurs déplacements ou transformations.
Puis ils sont devenus des dessins mais, même s'ils avaient la même forme,
ils restaient identifiés par un code non inscrit dans l'espace.
Désormais, leur identité est inscrite dans l'espace même, localement,
et pas dans la règle. Leur forme doit être reconnue reconnue par la règle
(pattern recognition) pour qu'ils puissent être manipulés.
Des objets complexes: chaque case de l'espace est munie de liens pour
s'accrocher à d'autres
Les objets peuvent être complexes: composés de combinaisons de plus d'une case
(à la différence des automates cellulaires)
Ceci permet à la forme des objets d'indiquer leur fonction.
Ceci permet aussi de transformer, trasporter et combiner les objets du modèle
facilement.
Les processus combinatoires (polymérisations) sont indispensables en biologie
Gem-graph ne peut pas représenter (la conservation de) l'énergie, mais
on peut convenir qu'à des formes d'objets identiques
sont associées des énergies potentielles identiques
(énergie potentielle = énergie que l'objet peut libérer ou stocker en étant
transformé)
Mouvement aléatoire de tous les objets = modèle d'une solution (sans le solvant)
Un seul format de règles pour décrire des mouvements et / ou des transformations
Qu'importent les structures, pourvu qu'elles représentent des fonctions !
Les conditions ne reconnaissent plus que des formes dessinées et deviennent
uniformes.
Séparation systématique des états et des règles de transition
Séparation des conditions et des actions des règles sous des formats standards
Espace plan enroulé sur un tore; matrice hexagonale
Plusieurs sites par 'particule'. Plusieurs flèches superposées.
Conditions d'une règle connectées par des 'ET'
Règles connectées par des 'OU'
Deux types de conditions: sur une cellule, sur une flèche
Deux types d'actions: translation, rotation
Condition de probabilité
Addition de modèles compatibles
Association possible de modèles gem-graph à de modèles décrivant des flux
et/ou des ondes
Un seul type de règle élémentaire (1 condition et 1 action, 1 seul symbole)
@sp 1
IL NE PEUT PAS Y AVOIR D'ÉCRITURE DE RÈGLE PLUS SIMPLE.
@sp 1
Commutativité
Un même moteur pour 1D, 2D et 3D
Les modèles et les préférences des utilisateurs sont stockés sous format XML
Des règles locales, aléatoires et asynchrones respectent les relations de
causalité
Parallélisme (premiers tests)
Arbre des conditions
Séparation des projets gem-graph (nommé fin 2020) et des projets biologiques
(aXoris, nommé vers 1995)
gem-graph est adapté à la représentation de tous les phénomènes complexes

@subsection Acknowledgements
@sp 1
Merci à ma famille d'avoir toléré et laissé s'exprimer ma folie à laquelle j'ai
consacré tant de temps.
C'est grâce à vous que j'ai appris à partager des moments heureux.
@sp 1
@auindex Boisard 'seb' Sebastien
@strong {Sébastien Boisard} que j'ai rencontré début 1994 a contribué à ce projet
en construisant, en C, un premier parseur des règles (efficace).
Il pensait en avoir "@emph {pour quelques jours}".
Il a entrepris ce travail à l'automne 1996 et l'a achevé en février 1998.
Puis il est est devenu ingénieur au CNRS et, plusieurs années après, a décidé de
'monter sa boite'.
@sp 1
Notre collaboration a été un bonheur et je le remercie profondément pour tout
ce qu'il m'a appris.
@sp 1
Son parseur a permis de manipuler jusqu'à 500 règles et a été un indice qui
nous a guidé vers de nouveaux développements possibles.
Il a notamment mis en évidence le fait qu'il fallait pouvoir manipuler
automatiquement (lire et écrire) de très grands nombres de règles
et que la structure de ces règles devait donc être simple et parfaitement définie.
@sp 1
Au début de son travail,
@itemize
@item ni la forme des règles, ni celle des états, ni les méthodes de modélisation,
 ni même le but des modèles, n'étaient clairement définis
@item Le choix du langage oscillait entre Pascal, C et Java
@item L'auto-production  avait été imparfaitement représentée (1993)
mais pas l'auto-re-production
@item Les règles étaient lues séquentiellement
@item Leur grammaire s'est stabilisée une première fois grâce à ce parseur fin 1995.
@end itemize
@sp 0
@c -
La grammaire des règles a continué à évoluer.
Par la suite, plusieurs parseurs Java ont été construits jusqu'à l'obtention
de la forme minimale (la plus simple possible) vers 2009 (?).

@sp 1
@auindex Bourmault 'neox' Adrien
En octobre 2020, @strong {Adrien 'neox' Bourmault} a eu connaissance de ce
travail et s'y est intéressé.
Son analyse et ses recommandations ont impulsés une réécriture complète du
code mais surtout une profonde réorganisation des méthodes.
Ce qui était jusque là une recherche artisanale a pu s'orienter,
grâce à son expérience et à sa rigueur, vers un travail d'équipe
avec l'objectif d'atteindre une qualité suffisante pour attirer
de nouveaux développeurs (et la labellisation GNU Project ?).
Cette première version témoigne à tous les niveaux de son implication.
@sp 1
Ses principaux apports ont été théoriques :
@itemize
@item choix d'une architecture modulaire client-serveur,
@item conception 'système' et non plus seulement objet,
@item méthodologie de développement
@end itemize
et pratiques :
@itemize
@item planification
@item choix d'une palette d'outils libres, actualisés et de qualité
  garantissant la cohérence de l'ensemble du développement:
  Guix, langage C, git, Libxml, Makefile, GTK4, OpenGL, Doxygen, Texinfo
@end itemize
@sp 1
Les principales étapes de cette réorganisation on été:
@itemize
@item En 2021, Architecture modulaire client-serveur
@item Redéfinition du fichier XML avec notation des règles sous forme d'arbre
    de conditions.
@item GIT
@item Début 2023 langage C, LibXML, OpenGL,
@item Automne 2024 Doxygen, Texinfo
@end itemize
@sp 1
Cette réorganisation a mis en évidence :
@itemize
@item Le sous-ensemble des flèche-origine (éligibles comme origine de l'espace local);
@item Les autres modes d'écriture possible des flèches (départ-arrivée,
  départ + module + angle);
@item Le parcours de l'espace local (espace de travail)
  est encodé par l'ordre des conditions dans l'arbre
	=> abandon des parcours séquentiels de listes de règles
	=> plusieurs parcours possibles (auparavant : le seul parcours spirale)
	=> optimisation souhaitable (par le client) du parcours pour chaque modèle
	   (dans tous les cas, la fabrication de l'arbre que le serveur utilisera
	   incombe au client)
@item Le cycle de vie du modèle : correction des erreurs reproductibles puis aléatoires;
@item Les outils nécessaires pour ces deux phases de la conception du modèle;
@item La fixation du vocabulaire est en cours / création d'un glossaire.
@end itemize
@sp 1
ref _bibliogaphie, _méthodologie
@sp 1
@auindex Sirmai 'jean' Jean
@cite {Sirmai, J. (2011). A Schematic Representation of Autopoiesis
Using a New Kind of Discrete Spatial Automaton.
Advances in Artificial Life, ECAL 2011, MIT Press.}

@cite {Sirmai, J. (2012). Autopoiesis Facilitates Self-Reproduction.
Advances in Artificial Life, ECAL 2012, MIT Press.}

@section Gem-graph as a medium for artistic expression
@cindex Gem-graph as a medium for artistic expression
@anchor {medium_for_artistic_expression}
(cf. @url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/10})
@glindex Poetry
Rewriting geometric graphs can also support artistic expression. It may help
creators to freely conceive and design shapes, movements, colours and sounds
they love. Gem-graph is an open-ended adventure! There can never be too much
poetry in this world!

@node bibliography
@node topics_and_concepts
@node authors
@node glossary
@node quotations


@unnumbered  Bibliography
@cite {Karr Jonathan R. A whole-cell computational model predicts phenotype
from genotype Cell. 2012 Jul 20;150(2):389-401. doi: 10.1016/j.cell.2012.05.044.}
@sp 1
@cite {McMullin Barry Thirty years of computational autopoiesis: a review
Artif Life. 2004 Summer;10(3):277-95. doi: 10.1162/1064546041255548}
@sp 1
@cite {Nehaniv, C. L. (2002). Evolution in Asynchronous Cellular Automata.
In Artificial Life VIII (pp. 65-73)}
@sp 1
@cite {Sirmai, J. (2011). A Schematic Representation of Autopoiesis Using a
New Kind of Discrete Spatial Automaton. Advances in Artificial Life,
ECAL 2011, MIT Press.}
@sp 1
@cite {Sirmai, J. (2012). Autopoiesis Facilitates Self-Reproduction.
Advances in Artificial Life, ECAL 2012, MIT Press.}
@sp 1
@cite {Smith, A., P. Turney, et al. (2002). JohnnyVon: self-replicating
automata in continuous two-dimensional space. NRC Publications Archive.}
@sp 1
@cite {Wishart, D. S., R. Yang, et al. (2005). Dynamic cellular automata:
an alternative approach to cellular simulation. In Silico Biol 5(2): 139-161.}
@sp 1
@url {https://forge.a-lec.org/gem-graph/Gem-graph/issues/10} (10 <--> 19)



@unnumbered Topics & Concepts Index
@printindex cp
@sp 1
@unnumbered Authors Index
@printindex au
@sp 1
@unnumbered Glossary
@printindex gl

@unnumbered Quotes
@section Nehaniv Chrystopher(2012)
@sp 1
Abstract
@sp 1
Building on the work of Von Neumann, Langton, and Sayama among others,
we introduce the first examples of evolution in populations of
self-reproducing configurations in asynchronous cellular automata.
Reliance on a global synchronous update signal has been a limitation
of all solutions since the problem of achieving self-production in
cellular automata was first attacked by Von Neumann half a century ago.
Results of the author obviate the need for this restriction.
@sp 1
We review our simple constructive mechanism to transform any cellular
automata network with synchronous update into one with essentially the
same behavior but whose cells may be updated randomly and asynchronously.
The generality of this mechanism is guaranteed by a general mathematical
theorem that any synchronous cellular automata configuration and rule can
be realized asynchronously in such a way that the behavior of the original
synchronous cellular automata can be completely recovered from that of the
corresponding asynchronous cellular automaton,
in which temporal synchronization locally stays within small tolerances.
@sp 1
It follows that most results on self-reproduction, universal computation
and construction, and evolution in populations of self-reproducing
configurationsin cellular automata that have been obtained in the past
carry over to the asynchronous domain using the method described here.
@sp 1
Here we discuss requirements for evolutionary systems in cellular automata
and describe implemented examples of our procedure applied to a variety of
self-reproducing systems (Byl, Reggia et al., Langton, Sayama).
@sp 1
In particular, we have implemented Sayama's evo-loop system asynchronously,
giving the first example of evolution in asynchronous cellular automata.
@sp 1
(extract page 2)
@sp 1
A @emph {cellular automaton} is a network of identical deterministic
finite state automata and a graph structure such that:
@enumerate
@item each node has the same (finite) number of neighbors,
@item at each node we have a fixed ordering on the neighbor nodes, and
@item the next state of an automaton at a node v is always the same
function of its current state and of the state of its neighbors.
@end enumerate
The graph describes the connexions of these automata.
A configuration is any assignment of local state values to the set of
automata at nodes in the graph.

@section  Sirmai Jean (2011)
In the 2011 and 2012 papers, the name "gem-graph" was not yet in use
and what is named "arrow" today and "symbol" in the following extract
was named "link" in 2011 and "index" in 2012.
It the 2012 paper, what is gem-graph today was presented as follows
NB The text has been simplified and reorganised, but no new concepts have
been introduced.
@sp 1
@emph {"a graph rewriting system embedded in a spatial automaton able by
combinations of a unique symbol to represent an unlimited variety of moving
and interacting objects.
Each transition associates a set of conditions to a set of operations.
All the conditions are the same type: they test the number of arrows in a
given location and orientation. All operations are of the same type: they
move an arrow from a place to another. The space is not explored using its
coordinates but according to its content. Each transition converts only a
part of the space. All information regarding the description of objects is
in the space. All information concerning their movements and interactions
is in the transitions. No other information is encoded. Transitions are
parallell, independent from each other and occur at random. They can
move, deform, transport, or transform objects, each object being an isolated
part of the graph. This formalism does not limit the variety of movements or
transformations that can apply to each object. A second-level language
could be superimposed to the first to recognize the objects and enable the
user to interact directly with them."}

@bye