manual: WIP: elements of gem-graph theory (not yet translated from French)

docs/rtfm/gem-graph.texi

@@ -3,11 +3,8 @@
 @setfilename gem-graph.texinfo
 @settitle Gem-Graph manual
 @copying
-Gem-graph manual. 
-
-Texinfo edition. 2024-11-26  
-
 Copyright @copyright{} 2024 Jean 'jean' Sirmai
+@sp 1
 
 @quotation
 Permission is granted to copy, distribute and/or modify this document
@@ -33,11 +30,11 @@ Texts.  A copy of the license is included in the section entitled
 @chapter Introduction
 @cindex Introduction
 
-Welcome to Gem-graph !
+Welcome to Gem-graph!
 @sp 1
-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? Gem-graph provides you with automatic transformation tools that allow you to move from drawing to drawing so that their evolution best describes what you want. Not only is it your design, but you can also decide how it evolves! 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 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 sequences and other results that interest you so that you can play them again.
+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. By providing you with automatic transformation tools, it allows you to conceive and apply the rules that create new drawings from the previous ones. Your design is no longer frozen: you can also 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. 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 sequences and other results that interest you so that you can play them again.
 @sp 1
-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 quite 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 does have 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 the space. All the dynamic information - your redrawing rules - transform what you draw as you wish. All the gem-graph rules, whatever their complexity, are only associations of an unique simple pattern: one condition on one element 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.
+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 quite 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 does have 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 the space. All the dynamic information - your redrawing rules - transform what you draw as you wish. All the 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
 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, @xref {node_gem_graph_by_example, Gem-graph by example, Hello world, Gem-graph 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 (_simple_model), observe it (_simple_observation), measure what it does (_simple_measurements) and display the results (_simple_results), then transform it by changing what you see (_simple_state_edition) and how it reacts (_simple_rule_edition). You can directly deal in with the details of gem-graph mechanism itself (_gem_graph_mechanism). You may also whish to compare gem-graph to other classes of automata that do quite similar things (_spatial_automata_classification), and examine what it can and cannot actually do and what its scope of application is (_gem_graph_theory).
 
@@ -45,19 +42,18 @@ One way of doing this is to reproduce very simple examples, such as when a progr
 @chapter Gem-graph by example
 @cindex Gem-graph by example
 
-
 @section Hello world
 @cindex 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 that gem-graph needs to know to execute such models is written in the "Hello world" file (_hello_world_file). Note that all the 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). 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.
+@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 that gem-graph needs to know to execute such models is written in the "Hello world" file (_hello_world_file). Note that all the 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). You can now detail this first example (_hello_world) or skip and continue reading to have a first approach of what the next models will show you.
 @sp 1
 @section Random walk
 @cindex 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. A random draw is also necessary to determine whether the first or second rule applies. With these two rules and the random draw, the arrow now sometimes advances and sometimes retreats at random. The detailed description is here: (_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. A random draw is now necessary to determine whether the first or second rule applies. With these two rules and the random draw, the arrow now sometimes advances and sometimes retreats at random. The detailed description is here: (_random_walk).
 @sp 1
 @section Multiple random walks
-@cindex Multiple random walks
+@cindex Random walks (multiple)
-@anchor {multiple_random_walks} The next example shows how these two rules can be applied to a 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 one arrow could 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 have designed can be applied.
+@anchor {multiple_random_walks} The next example shows how these two rules can be applied to a 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 have designed can be applied.
-By adapting the previous 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).
+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
@@ -65,12 +61,175 @@ By adapting the previous example, it's easy to create another model where the ar
 @sp 1
 @section Random walks plus pendulum
 @cindex Random walks plus pendulum
-@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). This addition is immediate because these three models are independent. If they were not, and if a rule in one applied to a state in another, it would be up to you 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).
+@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 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, we 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. We could have drawn several of them, but without guaranteeing their synchronisation! Nothing else happens (_random_walks_plus_pendulum). 
+Once the addition automatically operated, we 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 (_ergodicity, _gem_graph_theory). Note that we could have drawn several clocks, but without guaranteeing their synchronisation as long as they remained independent. This is because the automaton randomly selects the targets to which it applies the rules. (more on this here: _pendulums_synchronisation, _gem_graph_theory).
 @sp 1
 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 control this complexity. 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 quite similar things to better understand how the profound simplicity of its automaton allows it to embrace such a wide range of situations and behaviours simultaneously but also what it can and cannot do easily and what its scope is (_spatial_automata_classification).
 
+@node gem_graph_theory
+@chapter Gem-graph theory
+@cindex Gem-graph theory
+
+@section Models addition
+@cindex Models addition
+@anchor {models_addition} Trois conditions doivent être réunies pour pouvoir additionner des modèles :
+- 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. 
+* 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 :
+* 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.
+* 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.
+- 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).
+
+@section Tags
+@cindex Tags
+@anchor {tags} (cf. https://forge.a-lec.org/gem-graph/Gem-graph/issues/17)
+Un graphe géométrique peut être interprété comme un objet (graphe connexe), une situation (objets proches les uns des autres) ou un 'tag' (ou balise). Un tag 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 tags peut être associé à un dessin d'un objet ou d'une situation.
+le concepteur d'un modèle peut souhaiter ajouter des informations d'intérêt à un dessin (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 tags.
+Définir des normes faciliterait leur édition.
+
+@section Models coupling
+@cindex Models coupling
+
+@subsection Models coupling to flows
+@cindex Models coupling to flows
+@anchor {models_coupling_to_flows} (cf. 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.
+
+References
+    Smith, A., P. Turney, et al. (2002). JohnnyVon: self-replicating automata in continuous two-dimensional space. NRC Publications Archive.
+    Wishart, D. S., R. Yang, et al. (2005). Dynamic cellular automata: an alternative approach to cellular simulation. In Silico Biol 5(2): 139-161.
+
+@subsection Models coupling to waves
+@cindex Models coupling to waves
+@anchor {models_coupling_to_waves} (cf. 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.
+
+@section History
+@cindex History
+@anchor {history} (cf. https://forge.a-lec.org/gem-graph/Gem-graph/issues/11) 
+La conception d'une modélisation par réécritures de graphes géométriques s'est faite par étapes. L'élaboration de gem-graph a été un processus incessant qui ne peut être considéré comme achevé. L'étude de cette évolution pourrait aider à la conception des développements à venir et -peut-être ! - économiser des réécritures.
+
+De 1992 à 2020, chaque étape du développement a entraîné la réorganisation partielle ou complète du logiciel (structures de données, nommage et algorithmes) (ref) en réponse à des contextes historiques particuliers:
+
+    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)
+    Christopher Langton: 'Life as it is' versus 'Life as it could be'
+    Le 'jeu de la vie' John Horton Conway en 1970 :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)
+    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) 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
+
+En 2021, gem-graph a été réorganisé :
+
+    Architecture modulaire client-serveur
+    Conception 'système' et non plus seulement objet. (ref)
+    Redéfinition du fichier XML avec notation des règles sous forme d'arbre de conditions.
+
+Cette réorganisation a mis en évidence :
+
+    Le sous-ensemble des flèche-origine (éligibles comme origine de l'espace local)
+    Les autres modes d'écriture possible des flèches (départ-arrivée, départ + module + angle)
+    Le parcours de l'espace local est encodé par l'ordre des conditions dans l'arbre.
+        => abandon des parcours séquentiels de listes de règles.
+        => plusieurs parcours sont possibles (auparavant : le seul parcours spirale).
+        => le parcours peut être optimisé pour chaque modèle.
+        => ce travail d'optimisation (le choix d'un parcours) est attribué au client.
+        => le client fabrique donc l'arbre que le serveur utilisera.
+    Le cycle de vie du modèle : correction des erreurs reproductibles puis aléatoires.
+    Les outils nécessaires pour ces deux phases de la conception du modèle.
+    Fixation (en cours) du vocabulaire / création d'un glossaire.
+
+Réferences: (_bibliogaphie, _méthodologie)
+
+Sirmai, J. (2011). A Schematic Representation of Autopoiesis Using a New Kind of Discrete Spatial Automaton. Advances in Artificial Life, ECAL 2011, MIT Press.
+
+Sirmai, J. (2012). Autopoiesis Facilitates Self-Reproduction. Advances in Artificial Life, ECAL 2012, MIT Press.
+
+Remerciements
+
+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 "pour quelques jours" (sic). Il a entrepris ce travail à l'automne 1996 et l'a achevé en février 1998. Puis il est parti 'monter sa boite' et est devenu ingénieur au CNRS.
+
+Notre collaboration a été un bonheur et je le remercie profondément pour tout ce qu'il m'a appris.
+
+Ce 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 de très grands nombres de règles et donc que la structure des règles devait toujours permettre leur lecture et leur écriture par des algorithmes. Au début de son travail, 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. Le choix du langage oscillait entre Pascal, C et Java. L'auto-production (mais pas l'auto-re-production) avait été (imparfaitement) représentée dès 1993. Les règles étaient lues séquentiellement. Leur grammaire s'est stabilisée une première fois grâce à ce parseur fin 1995. Plusieurs parseur Java ont été construits par le suite.
+
+@section Gem-graph as a medium for artistic expression
+@cindex Gem-graph as a medium for artistic expression
+@anchor {medium_for_artistic_expression} (cf. https://forge.a-lec.org/gem-graph/Gem-graph/issues/10) 
+La réécriture de graphes géométriques est aussi une expression artistique. Les créateurs sauront s'en saisir pour associer librement formes, mouvements, couleurs et sons. Gem-graph est une aventure ouverte ! Il n'y aura jamais trop de poésie dans ce monde !...
+
+L'auteur de ces lignes a dégagé les principes de gem-graph et réalisé ses premiers prototypes de 1992 à 2020. Il s'est autorisé à rêver et à publier ses rêves, sans avoir réalisé que la réalisation de chacun d'eux coûterait des années d'effort. Puissent-ils cependant encourager l'expression et la liberté de chacun ! Il espère que ses erreurs seront fécondes et qu'aussi longtemps qu'il sera porté par l'enthousiasme, l'audace et la patience, le projet gem-graph éclairera ceux qui lui font confiance.
+
 @unnumbered Index
 @printindex cp
 @bye