Représentations dynamiques de l'espace dans un langage déclaratif de simulation

HAL Id: tel-00305731

https://tel.archives-ouvertes.fr/tel-00305731

Submitted on 24 Jul 2008

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

déclaratif de simulation

Olivier Michel

To cite this version:

Olivier Michel. Représentations dynamiques de l’espace dans un langage déclaratif de simulation.

Génie logiciel [cs.SE]. Université Paris Sud - Paris XI, 1996. Français. �tel-00305731�

UNIVERSITÉ DE PARIS-SUD

U.F.R. SCIENTIFIQUE D’ORSAY

THÈSE

présentée pour obtenir

le GRADE de DOCTEUR EN SCIENCES

DE L’UNIVERSITÉ PARIS SUD (XI)

Spécialité : INFORMATIQUE

par

Olivier Michel

Sujet :

Représentations dynamiques de l’espace

dans un langage déclaratif de simulation

Soutenue le 11 Décembre 1996 devant le jury composé de :

MM. Laurence Puel

Président

Gilles Bernot

Rapporteur

Patrick Sallé

Rapporteur

Edward Ashcroft

Examinateur

Jean-Louis Giavitto

Examinateur

Je remercie vivement Madame Laurence Puel, Professeur, Directrice du L.R.I., qui a bien voulu présider le jury de cette thèse.

Je veux sincèrement remercier Monsieur Gilles Bernot, Professeur à l’Université d’Évry Val d’Essonne et Monsieur Patrick Sallé, Professeur à l’I.R.I.T., d’avoir accepté d’être rapporteur de ma thèse. Je leur suis particulièrement gré d’avoir lu, avec toute l’attention et l’intérêt dont ils ont fait preuve, un bien épais manuscrit.

Je suis très honoré de la présence dans le jury de Monsieur Edward Ashcroft, Professeur à l’Arizona State University, père du langageLucid, dont les idées nous ont toujours inspirés et stimulés.

Monsieur Jean-Paul Sansonnet, Directeur de recherche au C.N.R.S., a accepté d’être le directeur de cette thèse. Les discussions que nous avons eues ont toujours été la source d’un grand plaisir et je l’en remercie sincèrement.

Monsieur Jean-Louis Giavitto, Chargé de recherche au C.N.R.S., a encadré cette recherche pendant trois ans ; qu’il reçoive ici mes remerciements les plus vifs.

Mon travail s’est déroulé dans un environnement fertile : l’équipe Architectures Parallèles du L.R.I. Je remercie Monsieur le Professeur Daniel Étiemble, responsable de l’équipe, de m’y avoir accueilli.

J’ai passé trois ans avec Abderrahmane Mahiout et Dominique De Vito sur le projet 81/2. Je les

remercie de leur constante gentillesse et de la qualité des discussions que nous avons eu pendant cette période. Je suis redevable à Julien Soula qui a effectué son stage de D.E.A. au sein de l’équipe et dont la maîtrise de Mathematicanous a permis de disposer d’un premier évaluateur de GBF. Franck Cappello et Franck Delaplace ont à la fois été des exemples de rigueur et ont su dispenser entrain et bonne humeur. Je les en remercie vivement.

L’objectif de ce travail est de concevoir et d’étudier des représentations dynamiques de l’espace dans le cadre d’un langage déclaratif. Le but est d’intégrer dans un langage informatique des structures de données proches des objets mathématiques utilisés dans la modélisation des systèmes dynamiques (SD), afin de simplifier l’expression des algorithmes et les programmes.

Ce travail a pour cadre le projet 81/2. Issu de l’équipe Architectures Parallèles du LRI, l’ambition initiale

du projet était de développer un langage parallèle pour la simulation des SD. Ce type d’applications représente la grande majorité des programmes exploités sur les super-ordinateurs.

Cela a conduit à développer des structures de données dédiées à la simulation des SD : le stream et la collection 81/2, et surtout, à étudier la compilation efficace des programmes déclaratifs définissant de telles

structures de données. Cet objectif a été en partie atteint, avec le développement d’un compilateur et l’étude de la distribution automatique des calculs.

Une constatation est alors venue réorienter les directions de recherche du projet 81/2: l’expressivité d’un

langage de simulation est au moins aussi importante que son efficacité. En effet, les objets modélisés par les simulations actuelles sont de plus en plus complexes et leurs interactions compliquées. Les algorithmes de simulation deviennent de plus en plus sophistiqués. Le peu d’expressivité d’un langage constitue alors un obstacle à la mise en œuvre de ces nouvelles simulations. Avec la montée en puissance des microprocesseurs, et la standardisation des logiciels de base permettant de travailler sur des réseaux hétérogènes de stations de travail, le nouveau challenge n’est plus seulement celui de la puissance de calcul mais aussi celui de la programmation des modèles.

Le problème posé au départ était d’étendre la notion de collection en 81/2afin de pouvoir programmer la

simulation de processus de croissance. L’exemple type visé est la simulation des L systèmes, un formalisme de réécriture parallèle utilisé dans la modélisation de la croissance des plantes. La simulation des L systèmes conduit à représenter un arbre dynamique et à évaluer des attributs sur cet arbre.

Cela m’a amené directement à la nécessité de manipuler des fragment de code, sous forme de termes ouverts. La systématisation de cette idée et sa formalisation a donné lieu à la notion d’amalgame. Les amalgames constituent un mécanisme puissant pour structurer et paramétrer les programmes déclaratifs sous la forme de « paquet d’équations ». Il est possible d’adopter plusieurs points de vue sur les amalgames : le point de vue qui nous intéresse plus particulièrement est le point de vue spatial. Un amalgame définit une notion d’espace irrégulier. En effet, pour raisonner sur les amalgames, il est commode de les représenter sous la forme d’un graphe data-flow : toutes les opérations de construction d’amalgames admettent alors une représentation graphique simple en termes de construction de graphe.

Dans le même temps, une autre partie de l’équipe 81/2développait les concepts nécessaire à la compilation

de définitions récursives de concaténation de tableaux. Ce problème nécessite de décrire de manière compacte le graphe data-flow des calculs entre les éléments du tableau. Nous nous sommes alors rendus compte que dans les deux cas on raisonnait sur le même objet, un graphe des dépendances, mais que dans un cas c’était un objet qui présentait une grande régularité (définition récursive de concaténation de tableaux) et que dans l’autre cas, il n’en présentait pas (les amalgames).

L’étude des régularités d’un graphe de dépendances d’une définition récursive de tableau a montré qu’on pouvait décrire ce graphe par la présentation d’un groupe mathématique, ce qui permet d’unifier le traitement d’autres structures de données récursives, comme par exemple les arbres. Par ailleurs, l’analogie avec les amalgames m’a convaincu de la nécessité de représenter des tableaux partiels, c’est-à-dire des tableaux dont

tous les éléments n’ont pas une valeur définie. Cela donne lieu à la notion de champ de données basé sur une structure de groupe ou GBF. Les GBF permettent la représentation d’espaces réguliers, où chaque point de l’espace a la même structure de voisinage. Cette représentation permet la définition de structures spatiales complexes exprimant en plus une information de type.

Si on revient à présent aux problèmes de simulation des SD, on voit que les GBF et les amalgames permettent de représenter deux sortes d’espaces (continu et discret) qui interviennent dans la description d’un SD. Les GBF sont particulièrement aptes à représenter la discrétisation d’une portion d’espace, comme on le fait par exemple pour la résolution numérique d’une équation aux dérivées partielles. Et les amalgames sont particulièrement aptes à représenter les relations structurelles entre les variables qui décrivent un SD. Mais ces nouveaux types de données dépassent leur motivation initiale : les amalgames sont utilisables dans le domaine de la programmation incrémentielle et les GBF s’inscrivent dans la ligne des travaux autour des types de données algébriques.

Organisation du document

Ce document se structure en quatre parties.

La première partie décrit le langage 81/2 . Les notions de stream, de collection et leur intégration dans

un langage déclaratif sont présentées. En particulier, les opérations sur les streams et les collections sont brièvement décrites, afin de permettre au lecteur de comprendre les exemples donnés. Nous rappelons à cette occasion l’approche intensionnelle du langage 81/2. Le dernier chapitre de la première partie donne des

exemples de SD. Ces exemples mettent en évidence l’adéquation du langage à la simulation des SD et nous donnons, tout au long du document, des exemples illustrant notre propos. Nous espérons qu’ils aideront à la compréhension des concepts décrits et des problématiques abordées.

La seconde partie de ce document définit et étudie la notion de GBF. Elle commence par la critique de la notion classique de tableau que l’on rencontre dans les langages évolués. Cette notion de tableau est trop pauvre pour la description de structures spatiales plus complexes que la grille euclidienne. Nous proposons d’étendre la notion de tableau en considérant un tableau comme une fonction partielle de l’ensemble de ses index vers un ensemble de valeurs. On munit cet index d’une structure de groupe. Cette structure définit les GBF. Nous détaillons dans cette partie les opérations sur les GBF et illustrons notre propos par de nombreux exemples pris dans des domaines aussi divers que un calcul de gaz sur un réseau, un processus de croissance ou un calcul de relaxation. Un schéma général d’implémentation des GBF est donné et détaillé dans le cas abélien. Les mécanismes décrits et les exemples donnés sont validés par des programmes enMathematica.

La troisième partie de ce document est consacrée aux amalgames. Nous mettons en évidence que la structure d’espace d’un GBF, décrite par la présentation d’un groupe, correspond aussi au graphe des dé-pendances d’un système 81/2, mais que ce graphe n’est pas forcément homogène. Un système 81/2est une

collection d’équations et nous nous posons la question de construire ces objets comme résultat d’un calcul. Pour cela, nous nous appuyons sur des systèmes ouverts, c’est-à-dire des systèmes impliquant des identifica-teurs auxquels ne correspond aucune définition. La définition des expressions ouvertes et d’un mécanisme de clôture des expressions par capture de nom donne lieu à la définition des amalgames. Trois opérateurs seule-ment permettent de construire des amalgames. Ces trois opérateurs ont une interprétation simple en termes de mécanismes de programmation. Une sémantique formelle des amalgames est ensuite développée dans le chapitre X. Cette sémantique, exprimée dans le style SOS, donne lieu à une implémentation enMathematica d’un interprète du calcul sur les amalgames. Le chapitre suivant illustre par des exemples l’utilisation des amalgames. Nous montrons en particulier la puissance expressive du formalisme à l’occasion du codage de l’arithmétique. Nous utilisons les amalgames pour la modélisation d’un processus de croissance.

Enfin, la dernière partie du document se propose d’intégrer les deux nouvelles structures de données dans le langage 81/2. Nous proposons une solution qui consiste à développer des streams d’amalgames de GBF.

Nous n’intégrons pas l’ensemble des GBF, mais nous nous restreignons à un sous-cas correspondant à des tableaux dynamiques. Cela nous oblige à définir une nouvelle sémantique 81/2D, dans le style opérationnel,

car la sémantique initiale de 81/2ne supporte pas les extensions dynamiques. Une implémentation enCAML est actuellement en cours. Malgré toutes ces restrictions, nous donnons dans le dernier chapitre des exemples significatifs de programmes 81/2D, et en particulier, la simulation d’une classe de L systèmes.

Remerciements

i

Introduction

iii

Table des matières

vii

Liste des exemples

xi

A

La simulation et les langages déclaratifs

1

I Simulation et langages déclaratifs 3

I.1 Les systèmes dynamiques . . . 4

I.2 Langages expressifs ou efficaces pour la simulation . . . 5

I.3 81/2: un langage expressif pour la simulation . . . 6

II Le langage déclaratif 81/2 9 II.1 Description du langage déclaratif 81/2 . . . 9

II.2 La notion de stream . . . 9

II.3 La notion de collection en 81/2 . . . 12

II.4 Combinaison de collections et de streams : le tissu 81/2 . . . 17

III Exemples d’expressions 81/2 19 III.1 Le wlumf . . . 19

III.2 L’équation de diffusion–réaction d’A. Turing . . . 20

III.3 Modélisation d’un processus de croissance . . . 22

III.4 Définition récursive de tableaux . . . 24

B

GBF

27

IV.2 Une notion de tableau insuffisante . . . 31

IV.3 Les théories étendant la notion de tableau . . . 37

V Champs basés sur une structure de groupe 43 V.1 Les formes . . . 44

V.2 Exemples de formes . . . 49

V.3 Construction de formes . . . 52

V.4 Les champs basés sur des groupes (GBF) . . . 56

V.5 Opérations sur les GBF . . . 57 vii

V.6 Définition récursive d’un GBF . . . 61

V.7 Éléments d’implémentation . . . 64

VI Implémentation de GBF abéliens 69 VI.1 Outils théoriques pour l’implémentation des GBF abéliens . . . 69

VI.2 Implémentation enMathematica . . . 71

VII Exemples de GBF 73 VII.1 Exemple de combinaison de sous-champs . . . 73

VII.2 Résolution numérique d’une équation aux dérivées partielles . . . 74

VII.3 Relaxation red-black . . . 76

VII.4 Le modèle des gaz sur réseau . . . 77

VII.5 La croissance de l’ammonite hexagonale . . . 79

VII.6 La construction d’une spirale dans H2 . . . 80

C

Amalgames

83

VIII.2 Système et graphe data-flow . . . 87

VIII.3 Construction des DFG . . . 88

VIII.4 Les amalgames . . . 91

VIII.5 Simulation et construction de DFG . . . 97

VIII.6 Un aperçu des problèmes posés par l’évaluation des amalgames . . . 102

IX Les amalgames et les formalismes existants 109 IX.1 Les modes de liaison des identificateurs . . . 109

IX.2 Enregistrements et langages orientés objets . . . 111

IX.3 Les théories de noms . . . 114

IX.4 La programmation incrémentielle . . . 119

IX.5 Les langages réflexifs . . . 123

X Une sémantique des amalgames 129 X.1 Le langage de base des amalgames . . . 129

X.2 Le langage ΣI . . . 132

X.3 Les règles de réduction des termes de Σ . . . 135

X.4 Trois propriétés importantes de l’évaluation . . . 138

X.5 Discussion sur les règles de réduction . . . 139

X.6 Preuves du chapitre . . . 143

XI Éléments d’implémentation et exemples 159 XI.1 Éléments d’implémentation enMathematica . . . 159

XI.2 Exemple d’expressions d’amalgame purs . . . 161

XI.3 Extension du calcul sur les amalgames aux types de bases . . . 166

D

8

: GBF et Amalgames dans 8

173

XII.2 Intégration des GBF dans 81/2 . . . 177

XIII Une sémantique pour 81/2D 183

XIII.1 Syntaxe des expressions . . . 183

XIII.2 Principes de la sémantique . . . 184

XIII.3 Les domaines sémantiques . . . 186

XIII.4 Conventions . . . 187

XIII.5 Les règles de la sémantique opérationnelle de 81/2D . . . 188

XIII.6 Preuves d’évaluation de programmes 81/2D . . . 202

XIV Éléments d’implémentation et exemples 209 XIV.1 Éléments d’implémentation . . . 209

XIV.2 Structures de données dynamiques pour la combinatoire . . . 210

XIV.3 Calcul symbolique en 81/2D . . . 213

XIV.4 Exemples de modélisations et de simulations . . . 216

Conclusion

223

Annexes

229

A.2 Le programme 81/2 . . . 230

B Implémentation du calcul des amalgames en Mathematica 231 B.1 Les termes des amalgames, leur écrivain 81/2et LATEX . . . 231

B.2 La liaison des expressions . . . 232

B.3 La traduction de ΣI en ΣC . . . 232

B.4 Le prédicats C() et les fonctions annexes . . . 233

B.5 L’interprète proprement dit . . . 234

B.6 Exemple de session Mathematica . . . 234

C Le codage de l’arithmétique en amalgames 237 D 8,5D: un environnement pour 81/2D 239 D.1 L’environnement 8,5D . . . 239

D.2 Principe de l’intégration . . . 239

D.3 Les contextes graphiques 8,5D . . . 240

D.4 Sémantique des attributs d’un contexte graphique . . . 240

E Comparaison des notions abordées dans ce document 245

Bibliographie en relation avec ce travail

249

Bibliographie du document

251

III.1 Description et simulation d’une créature artificielle, le « wlumf ». . . 20

III.2 L’équation de diffusion–réaction d’après A. Turing . . . 22

III.3 Modélisation par une collection statique de la croissance de l’ammonite . . . 23

III.4 Définition d’une collection par récursion spatiale . . . 24

V.1 Une grille en deux dimensions « bi-directionnelle » . . . 48

V.2 Définition d’un voisinage triangulaire . . . 51

V.6 Définition récursive de iota comme un GBF . . . 62

VII.1 Partition complexe d’un champ sur un cylindre . . . 73

VII.2 Résolution numérique d’une équation aux dérivées partielles parabolique par les GBF . . 75

VII.3 Un calcul de relaxation « red-black » . . . 76

VII.4 Exemple de simulation d’une méthode de gaz sur réseaux en GBF . . . 77

VII.5 Simulation du processus de croissance de l’ammonite sur un réseau hexagonal . . . 79

VII.6 La construction d’une spirale logarithmique sur un réseau hexagonal . . . 80

VIII.5 Définition paramétrée d’une créature artificielle . . . 98

XI.2 Calcul de prédicats booléens par les amalgames . . . 161

XI.2 Codage des fonctions arithmétiques récursives totales par les amalgames . . . 162

XI.2 Calcul de (1 + 2) en amalgames purs . . . 165

XI.3 Calcul de factorielle par les amalgames . . . 167

XI.3 Calcul de fibonacci par les amalgames . . . 167

XI.3 Modélisation de la croissance d’une structure unidimensionnelle . . . 169

XI.3 Modélisation objet par les amalgames . . . 171

XIII.6 Calculs formels de l’horloge de quelques streams caractéristiques dans 81/2D . . . 202

XIV.2 Calcul du triangle de Pascal . . . 210

XIV.2 Calcul des nombres de Stirling . . . 212

XIV.2 Calcul des nombres d’Euler . . . 212

XIV.2 Construction récursive du triangle de Pascal modulo 2 . . . 213

XIV.3 Calcul symbolique d’un développement limité : exemple de l’exponentielle . . . 214

XIV.3 Calcul symbolique de la suite de Fibonacci . . . 215

XIV.3 Factorisation du calcul d’un arbre de calculs fonctionnels . . . 215

XIV.4 Calcul des nombres premiers par la méthode du crible d’Eratosthenes . . . 216

XIV.4 Codage des D0L systèmes en 81/2D . . . 218

XIV.4 Simulation du processus de croissance de la bactérie Anaeba catenula . . . 219

XIV.4 Modélisation du processus de croissance de l’ammonite en 81/2D . . . 219

René Thom (in Paraboles et catastrophes)

L’espace est une représentation nécessaire a priori qui sert de fondement à toutes les intuitions extérieures. On ne peut jamais se représenter qu’il n’y ait pas d’espace, quoique l’on puisse bien penser qu’il n’y ait pas d’objets dans l’espace. Il est considéré comme la condition de la possibilité des phénomènes, et non pas comme une détermination qui en dépende, et il est une représentation a priori qui sert de fondement, d’une manière nécessaire, aux phénomènes extérieurs. Emmanuel Kant (in Critique de la raison pure)

- Garçon !

- Monsieur?... Le bar est fermé, Monsieur... Monsieur désire quelque chose? - Oui..., de l’espace...

- Pardon?

- Un peu d’air... Vous avez compris?... Barrez-vous !

Henri-Georges Clouzot, Jean Ferry (in Quai des Orfèvres)

Tout autre est le rhizome, carte et non pas calque.[...] La carte est ouverte, elle est connectable dans toutes ses dimensions, démontables, renversable, susceptible de recevoir constamment des modifications. Elle peut être déchirée, renversée, s’adapter à des montages de toute nature, être mise en chantier par un individu, un groupe, une formation sociale. [...] Gilles Deleuze, Félix Guattari (in MILLE PLATEAUX )

La simulation et les langages déclaratifs

Simulation des systèmes dynamiques et

langages déclaratifs : l’approche 8

1/2

Dans cette première partie nous défendons l’idée d’un langage de programmation de haut-niveau pour la simulation des systèmes dynamiques. Les systèmes dynamiques sont un cadre très général pour modéliser des phénomènes décrits dans l’espace et qui évoluent dans le temps. L’étude de ces modèles, qui se retrouvent dans tous les domaines, passe très souvent par la simulation.

Le langage 81/2a développé des structures de données adaptées à la représentation de l’état d’un système

et à la représentation de sa trajectoire (la suite des états dans le temps). Ces structures de données sont intégrées dans un cadre déclaratif, ce qui rapproche le programme des formalismes mathématiques utilisés naturellement dans les modèles.

Cependant, les structures de données offertes par 81/2 sont encore trop rudimentaires, surtout lorsqu’il

s’agit de traiter les aspects dynamiques de la représentation spatiale d’un système. Ces aspects interviennent quand il faut simuler des processus de morphogénèse ou bien quand il faut calculer l’espace des états conjoin-tement à l’évolution du système.

L’objet de ce travail est de développer de nouvelles représentations informatiques de l’espace, aptes à répondre à ces problèmes.

Structure de la partie. Cette partie est composée de trois chapitres. Dans le premier chapitre nous examinons la problématique d’un langage de programmation pour la simulation, qui doit répondre à la fois à des problèmes d’efficacité et d’expressivité.

Dans le deuxième chapitre, nous présentons succinctement le langage 81/2. En particulier, les opérations

sur les streams et les collections sont brièvement décrites, afin de permettre au lecteur de comprendre les exemples donnés tout au long de ce document. Un stream est la représentation informatique d’une trajectoire, et une collection correspond à la représentation informatique d’un domaine de l’espace.

Le troisième chapitre illustre les notions introduites à travers des exemples. Deux exemples serviront de « fil rouge » tout au long de ce document : il s’agit de la modélisation du comportement d’une créature artificielle rudimentaire, le wlumf, et de la simulation grossière de la croissance d’un coquillage, l’ammonite. Structure du chapitre. Ce chapitre commence par introduire la notion de système dynamique, puis com-pare les objectifs d’efficacité et d’expressivité d’un langage de programmation dédié à la simulation des systèmes dynamiques. Le cadre général du projet 81/2est ensuite présenté.

I.1 Les systèmes dynamiques

La description des phénomènes dynamiques fait appel à la notion de système et d’état d’un système. Un système est un ensemble d’entités telles qu’on ne peut définir la fonction ou les variations de l’une, indépendamment de celles des autres.

Nous donnons le nom général de système dynamique (ou SD) aux modèles qui décrivent dans l’espace un état qui évolue dans le temps. La modélisation et la simulation des SD représente un domaine d’application très important. En effet, les besoins en simulation de SD se retrouvent par exemple dans tous les domaines où on peut difficilement effectuer une expérimentation :

– soufflerie numérique, – simulations nucléaires, – résistance des matériaux, – évolution des éco-systèmes,

– modélisation des semi-conducteurs et des supra-conducteurs, – chromo-dynamique quantique,

– dynamique moléculaire et réactions chimiques, – croissance de cristaux et problèmes de morphogénèse,

– et finalement toutes les applications de « réalité virtuelle » correspondant à la simulation de phénomènes dans un monde abstrait.

Les entités constituant le système sont caractérisées par des grandeurs appelées variables dont la valeur évolue au cours du temps. L’ensemble des variables qui décrit le système forme l’état du système. Les variations dans le temps de cet état composent la trajectoire du système et constituent le phénomène que l’on veut modéliser. L’espace dans lequel se déroule le phénomène correspond à l’ensemble des variables.

Il existe de nombreux formalismes différents pour décrire un SD. Par exemple, les physiciens classent traditionnellement les modèles de systèmes dynamiques suivant le type continu ou discret de l’état, du temps et de l’espace. La table 1 donne des exemples de formalismes utilisés pour décrire ces SD.

Initialement application de l’informatique, la simulation devient elle-même un paradigme de programma-tion et, de ce fait, un langage de haut-niveau pour la simulaprogramma-tion développe un nouveau modèle de program-mation. En effet, les phénomènes du monde physique constituent, sous une forme idéalisée, les objets d’un nouveau calcul. On peut identifier les relations qui existent entre les étapes de modélisation et de simulation d’un SD et les étapes de construction d’un programme :

description d’un monde _≡ programme informatique

paramètres de la description _≡ données du programme

phénomènes dans le monde décrit _≡ résultats du calcul

C: continu, D: discret. Équation aux dérivées partielles Équation différentielle Réseau d’itérations couplées Automate cellulaire Espace C D D D Temps C C D D État C C C D

Tab. 1 –Divers formalismes utilisés pour la modélisation de SD et leur caractérisation (continu, discret) par rapport à l’espace, le temps et l’état. Le seul moyen de décrire et d’étudier le comportement de ces formalismes passe souvent par la simulation. Celle-ci étant faite sur un ordinateur digital, il est nécessaire de discrétiser le temps, l’espace et les valeurs décrivant l’état. Cependant, le programme à écrire pour la résolution d’une équation aux dérivées partielles est très éloigné du programme d’un automate cellulaire : le nombre d’états en jeu dépasse de plusieurs centaines d’ordres de grandeur l’espace des états d’un automate cellulaire et un flottant IEEE est une bonne approximation d’une variable réelle. Mais il existe un cadre commun à tous ces formalismes, et que doit prendre en compte un langage dédié à ce type de simulation, c’est la représentation du temps et de l’espace.

Ce point de vue fertile est à l’origine de l’invention de nouveaux algorithmes (comme par exemple les procédures de recuit-simulé, les algorithmes évolutionnistes, les réseaux neuro-mimétiques...), et participe plus généralement d’un domaine de recherche nouveau, identifié sous le nom « Parallel Problem Solving from Nature » [SM91].

I.2 Langages expressifs ou efficaces pour la simulation des systèmes

dynamiques

Les applications de simulation des SD nécessitent de grandes puissances de calcul. Elles représentent d’ailleurs la majorité des applications des super-ordinateurs actuels. L’initiative du « Grand Challenge » [NSF91] qui a pour but le développement de l’infrastructure matérielle et logicielle pour atteindre le tera-ops, rappelle que l’expérience numérique, devenue indispensable dans toutes les disciplines scientifiques, n’est envisageable que si on dispose des ressources de calcul nécessaires. Cela est vrai surtout dans le domaine de la prédiction par simulation. Par exemple, les premières simulations, en 1950 par Von Neumann, d’un modèle de cir-culation atmosphérique barotrope (c’est-à-dire négligeant les variations de température le long des surfaces isobares), effectuée sur l’ E.N.I.A.C., ont permis de calculer l’évolution météorologique sur une durée de 24 heures dans une région donnée [CFVN61]. Hélas, la simulation avait nécessité 24 heures de calculs !

Un langage de programmation ne peut avoir aucun impact sur l’efficacité du modèle. Il peut par contre permettre une utilisation optimale des ressources fournies par l’architecture sur laquelle est exécuté le pro-gramme. Cependant, un langage pour la simulation se doit aussi d’être expressif.

La notion d’expressivité correspond aussi à un critère d’efficacité, mais cette fois-ci elle concerne la tâche de programmation. En effet, la simulation correspond à une méthode où l’on extrait un modèle d’un phénomène que l’on désire étudier, afin de pouvoir effectuer des expériences à partir de ce modèle, et étudier son comportement dans des situations diverses. Un modèle est toujours une représentation simplifiée du phénomène que l’on désire simuler, mais il doit en conserver les caractéristiques principales, afin que les conclusions de la simulation soient en rapport avec le système étudié. Pour pouvoir définir efficacement un modèle, il est nécessaire de définir un formalisme qui soit le plus proche possible de la classe d’applications que l’on désire modéliser. Si on essaye de formaliser un SD à l’aide d’un langage impératif classique, il est évident que la majeure partie du temps sera consacré à la résolution de problèmes d’intendance tels que :

– la représentation des entités de la simulation, – la gestion de la mémoire,

– la représentation du temps logique et sa gestion,

– la gestion du séquencement des activités des entités de la simulation.

Un langage pour la simulation des SD doit donc offrir des concepts de haut-niveau pour faciliter la pro-grammation des applications. Cet objectif n’est pas nécessairement antinomique avec un objectif d’efficacité. En effet :

– Il est rappelé dans [NSF91] que l’augmentation de la taille des problèmes traités est due en parts égales à :

1. l’augmentation des performances du matériel, 2. la sophistication des algorithmes.

Par conséquent, en permettant d’exprimer des algorithmes plus sophistiqués, on améliore aussi l’effica-cité de la simulation. Par ailleurs, il faut prendre conscience [FKB96, Zim92, GG96, Can91, MGS94] que l’utilisation de langages rudimentaires comme Fortran77 empêche le développement de nouveaux algorithmes (cf. le développement des nouveaux solveurs et des nouvelles librairies scientifiques en

C++ [BLQ92, KB94, ASS95, HMS+_{94, PQ93, PQ94, LQ92]).}

– Un langage de haut-niveau, puisqu’il est indépendant d’un architecture matérielle particulière, conduit de facto au développement de programmes plus portables puisqu’ils ne sont pas liés à une implémen-tation particulière, et sont donc plus aptes à profiter des évolutions technologiques.

– Un langage de haut-niveau peut se compiler efficacement, tout au moins pour la partie du langage qui peut s’implémenter efficacement ! Si les concepts offerts par un langage de haut-niveau sont proches

d’une application, mais que ces concepts s’implémentent mal sur une architecture donnée, alors la probabilité est grande que cette application sera inhéremment inefficace, quel que soit le langage utilisé pour la coder.

I.3 8

: un langage expressif pour la simulation

Le but poursuivi par le projet 81/2est l’étude et le développement de structures de données et de contrôle

permettant une programmation expressive des applications de SD. L’implémentation efficace de ces structures est aussi étudiée, et donne lieu au développement d’un langage expérimental nommé 81/2.

Le langage 81/2a adopté un style déclaratif de programmation. En effet, l’utilisation d’un style déclaratif

permet de considérer que les lois d’évolution du SD, exprimées sous la forme de relations fonctionnelles entre variables, constituent un programme.

Nous avons vu que la simulation d’un SD nécessite l’expression de l’évolution des variables d’un système dans deux dimensions particulières : l’espace et le temps. La variation, en 81/2, d’une valeur dans le temps est

rendue par une structure de données adaptée : la série ou stream. La représentation de l’état d’un domaine de l’espace conduit au concept de collection : un ensemble structuré de valeurs qui est manipulé comme un tout homogène. La combinaison de ces deux structures de données est appelée un tissu : un tissu représente la trajectoire, dans le repère htemps, espace, valeuri d’un SD (voir la figure 1).

Espace

Valeurs

Temps

les Structures Dynamiques

tiss u

Fig. 1 –Un tissu spécifié par une équation 81/2 est un objet dans le repère htemps, espace, valeuri. Un

stream est une valeur variant dans le temps ; une collection représentant la variation d’une valeur dans l’espace. La variation de l’espace dans le temps détermine une structure dynamique.

Objectif de ma thèse

C’est dans cette perspective que s’inscrit le travail de cette thèse. L’objectif du travail que nous présentons dans ce document est de concevoir et d’étudier des représentations dynamiques de l’espace dans un cadre déclaratif. En effet, l’intégration de modèles de données proches des objets mathématiques utilisés, doit permettre de réduire d’avantage le fossé entre modèles et langages de programmation, afin de simplifier les algorithmes et les programmes.

Notre motivation principale est de pouvoir développer facilement :

• la simulation des phénomènes hautement dynamiques, comme les phénomènes de morphogénèse ; • la simulation de SD pour lesquels l’espace des états n’est pas connu a priori, mais doit être calculé

La suite de cette partie est consacrée à la présentation du langage 81/2 tel qu’il existe et est défini

dans [Gia91a, GS93]. Les concepts que nous développons sont motivés et illustrés par des exemples de taille restreinte en lignes de code, mais néanmoins représentatifs des problèmes que l’on rencontre en simulation. Nous les illustrons aussi par des exemples purement informatiques, car les concepts étudiés dépassent le champ d’application de la simulation de SD et présentent un intérêt « pour eux-mêmes ».

La deuxième partie de ce document étudie la représentation d’un espace homogène à l’aide d’une nouvelle structure de donnée déclarative : le champ basé sur un groupe.

La troisième partie étudie la représentation d’un espace hétérogène à travers le concept d’amalgame. Enfin, la quatrième partie intègre ces deux nouvelles structures de données dans le langage 81/2, définissant

Le langage déclaratif 8

1/2

II.1 Description du langage déclaratif 8

Le langage 81/2est un langage déclaratif : un programme est un ensemble d’équations qui définissent des

tissus. Un tissu est la combinaison de la notion de stream et de collection. La dimension « stream » d’un tissu permet de représenter la trajectoire d’un SD ; la dimension « collection » permet de représenter son état.

Une équation 81/2est de la forme :

id = expr

où id est un identificateur et expr une expression pouvant faire référence à d’autres identificateurs de tissus. On dit que id est le definiendum et expr le definiens. Cette équation peut se lire comme une définition (celle de id) mais aussi comme une relation qui doit être maintenue vraie entre le tissu id et les tissus qui apparaissent dans expr.

Pour des raisons de simplicité, nous allons d’abord présenter la notion de stream, puis celle de collection. Les opérations définies sur un stream s’appliquent à un tissu, en considérant la dimension stream du tissu. Il en va de même pour les opérations agissant sur les collections.

II.2 La notion de stream

Pour simplifier le traitement formel des programmes, Tesler et Enea [TE68] ont défini la notion de langage à assignation unique. Afin de prendre en compte les structures de contrôle itératives, une variable ne pouvait alors plus dénoter une valeur unique, mais devait être étendue pour pouvoir dénoter une suite (éventuellement infinie) de valeurs. De telles suites infinies de valeurs, appelées streams, peuvent être ma-nipulées intensionnellement, c’est-à-dire comme des touts sans faire explicitement référence aux éléments la constituant.

La notion de stream permet de représenter les itérations d’une manière « mathématiquement respectable » pour citer [WA85] et même [Wat91] : « les expressions sur les suites infinies de valeurs sont aux boucles ce que la programmation structurée est aux gotos ».

Cette approche a donné lieu au développement du paradigme data-flow sous des formes très diverses et dans des domaines d’applications variés. Dans un modèle data-flow, ou plus généralement dans les langages de programmation déclaratifs, les données sont spécifiées par des équations (dans un langage data-flow, ce sont les streams qui sont spécifiés par des équations). Depuis le langage Lucid [WA76], bien des langages s’inspirant du modèle data-flow ont été proposés : Lustre[CPHP87] et Signal [GBBG86] dans le domaine de la programmation temps-réel, Crystal [Che86] pour la conception et le développement d’algorithmes systo-liques,Palasm [SG84] pour la programmation des PLDs,Daisy[Joh83] pour la conception des circuits VLSI,

81/2 [Gia91b, MDVS96] pour la simulation parallèle, Unity [CM89] pour la spécification abstraite des pro-grammes parallèles, etc. De plus, la définition déclarative de streams est un sous-produit naturel de l’analyse de dépendances d’un langage impératif conventionnel commeFortran(dans ce cas, un stream correspond aux valeurs successives prises par une variable dans une boucle).

II.2.1

Les streams synchrones

Les streams synchrones ont été proposés dans les langages Lustreet Signal comme un outil pour la pro-grammation des systèmes réactifs temps-réels. Dans ces deux langages, la succession des éléments dans un stream est fortement liée à la notion du temps : l’ordre de calcul des éléments dans le stream est le même que l’ordre de succession de ses éléments [PKL93].

Cette propriété n’est pas vraie enLucid: le calcul de l’élément i du stream A peut nécessiter le calcul de la valeur de l’élément i + 1 de A. Par ailleurs, le calcul de l’élément i du stream A n’est pas synchronisé avec le calcul de l’élément i d’un stream B. A l’opposé, la synchronisation des calculs est un contrainte fondamentale enLustreou enSignal1. Par exemple, l’expression

A + B

où A et B sont des streams (le résultat est un stream dont le ie_{élément a pour valeur la somme des i}e_éléments des streams A et B), n’est permise que si le calcul des éléments de A et de B prend place au même instant. Ce type de contrainte requiert que les streams A, B et A+B partagent une référence temporelle commune : l’horloge du stream. De plus, on restreint les expressions de streams de telle manière que le calcul d’un élément du stream ne fasse référence qu’à un ensemble statiquement limité de valeurs précédentes du stream [Cas92]. De cette manière, on peut identifier la succession des éléments dans un stream avec le passage du temps dans le programme.

II.2.2

Les streams 8

Les streams du langage 81/2partagent avec l’approche précédente l’idée de comparer l’ordre d’occurrence

d’un élément dans des streams différents, mais il est toujours possible de composer deux streams. Ainsi, le stream A + B est toujours défini. Pour que cette expression ait un sens bien défini, il est nécessaire que tous les streams partagent une référence temporelle commune : un temps global partagé. Les instants de ce temps global partagé sont appelés tics. L’ensemble des instants pour lesquels un élément du stream A est évalué est appelé horloge de A et correspond aux tops2_{du stream. Les valeurs d’un stream étant « égrenées » dans}

le temps, nous appellerons valeur instantanée d’un stream la valeur de l’élément correspondant à l’instant courant.

L’horloge d’un stream correspond à l’ensemble des instants sur lesquels on doit déclencher un calcul afin de continuer à satisfaire la définition du stream. Par exemple, l’horloge de A + B est constituée de l’union des horloges de A et de B puisque la valeur instantanée de A + B est susceptible de changer quand la valeur instantanée de A ou de B change, c’est-à-dire si l’instant courant appartient à l’horloge de A ou de B. La valeur d’un stream est cependant observable à tout instant et sa valeur instantanée est la valeur calculée au premier tic précédent dans son horloge.

On peut dire que le concept de stream enLustreouSignal correspond à une logique de signal instantané tandis que le stream 81/2correspond à une logique de niveau. La notion d’horloge en 81/2correspond donc

plutôt à la spécification des instants où ces valeurs doivent être produites plutôt qu’aux instants où elles doivent être consommées. De plus, la valeur courante d’un stream est toujours utilisable. Cela ne permet donc pas à 81/2d’exprimer des contraintes temps-réel (comme par exemple d’exprimer que l’horloge de deux

streams doit être la même, comme le permet la primitive synchro du langage Signal). En revanche, il est plus facile de composer arbitrairement des streams, ce qui est nécessaire par exemple pour l’expression des trajectoires d’un système dynamique [MGS94].

1. Elle permet de spécifier par exemple qu’une action doit avoir lieu à une heure fixe, midi pile par exemple, un genre de contrainte qu’on veut usuellement exprimer dans les applications temps-réel, cf. [BB91, Hal93] pour une introduction générale à la programmation temps-réelle synchrone.

II.2.3

Les opérations sur les streams

Dans cette section, nous allons présenter succinctement un certain nombre d’opérateurs qui agissent sur les streams. Nous utiliserons la notation suivante :

< 1; 2; 2; 2; 3; 4; . . . <

pour désigner un stream dont le premier élément vaut 1, le deuxième 2, etc. Les tics faisant partie de l’horloge du stream sont représentés par des valeurs soulignées. Dans l’exemple précédent, les tics 0, 1, et 4 (la numérotation des éléments d’un stream commence à 0) sont des tics de l’horloge mais aussi des tops.

II.2.3.1 Les constantes

Une constante n dénote le stream : < n; n; n; n; n . . . <

La constante Clock 0 dénote le stream : < true; true; true; true; true; . . . <

Plus généralement, la constante Clock n (avec n ≥ 1) dénote le stream de booléens vrais ayant un top tous les n tics ; pour une valeur négative de n, le stream de booléens ayant un top tous les tics avec une probabilité de 1/n.

II.2.3.2 Le retard ou délai

L’opérateur de retard permet de référencer la valeur d’un stream au top précédent. Un stream A retardé se note $A. Nous donnons dans la table 1 un exemple de stream retardé.

Numéro de tic 0 1 2 3 4 5 6 . . .

A 1 2 2 2 3 3 4 . . .

$A nil 1 1 1 2 2 3 . . .

Tab. 1 –Exemple de stream retardé

L’horloge d’un tissu A retardé est identique à l’horloge de A au premier top près. La valeur de $A est définie à partir du tic consécutif au premier tic de A.

II.2.3.3 La quantification des équations

Il est parfois nécessaire de spécifier une valeur à un top donné (par exemple pour spécifier une valeur initiale). Pour ce faire, on utilise la quantification des équations. La définition :

S@0 = A;

permet d’indiquer que la valeur du premier top de S est donnée par la valeur du premier top de A. L’opérateur @ (at) limite la portée d’une équation à un top donné : celui de son argument, qui est obligatoirement une constante entière.

Le programme suivant : S@0 = A;

S = B;

définit la valeur de S comme étant celle de A sur le premier top et celle de B après. L’équation S = B n’est pas quantifiée et s’applique quand aucune équation quantifiée ne peut s’appliquer. Par exemple, si :

B ⇒ < 3; 4; 4; 4; 5; . . . < alors :

S_{⇒< 0; 4; 4; 4; 5; . . . <}

Le signe ⇒ se lit : « s’évalue en ». Il est possible de définir autant de quantifications que nécessaire sur un stream.

II.2.3.4 L’échantillonneur

Dans l’équation : S = A when B;

le stream B doit être un stream de valeurs booléennes. L’horloge du stream résultat est constituée des tops de B sur lesquels B est vrai. La valeur du stream résultat est la valeur du tissu A sur les tops de la nouvelle horloge.

L’opération d’échantillonnage est une opération de contrôle : elle peut être considérée comme une vanne permettant de faire (ou de ne pas faire) passer le flot des valeurs de A. C’est pourquoi cet opérateur est appelé un échantillonneur, cf. table 2.

Numéro de tic 0 1 2 3 4 5 6 7 8

A 1 2 2 3 4 4 5 6 6

B nil nil false true false true true false false

A when B nil nil nil 3 3 4 5 5 5

Tab. 2 –Exemple de stream échantillonné par l’opérateur when

En 81/2, il existe d’autres opérations d’échantillonnage sur les streams (until, after, at) que nous ne

présenterons pas ici. Le lecteur se reportera à [Gia91a] pour une définition des variantes existantes.

II.3 La notion de collection en 8

II.3.1

Collections et opérations intensionnelles

Une collection est un agrégat d’éléments qu’on peut manipuler comme un tout. Par exemple, les tableaux en APL [FI73] sont des collections. Par contre, les tableaux en Pascal ne sont pas des collections car la principale opération permise sur un tableau est l’accès à un seul élément : par conséquent il n’est pas possible de les manipuler globalement (par une opération d’addition de deux tableaux par exemple).

La structure de collection est présente dans de nombreux langages de programmation. Nous citerons, par exemple, l’ensemble (SETL[SDDS86]), le multi-ensemble (GAMMA[BCM88]), le vecteur (*LISP[Thi86]), l’imbrication de vecteurs (NESL[Ble93], 81/2[Gia91a]) et bien sûr le tableau multidimensionnel (APL[Ive87], HPF[Ric93],MOA[HM91],indexical Lucid [AFJW95], etc.)

II.3.2

Les collections en 8

Les éléments d’une collection se notent entre accolades { . . . , . . . }, chaque élément étant séparé par une virgule ou un point-virgule. En 81/2, il y a deux types de collections. Le premier type de collection correspond

à des imbrications homogènes de vecteurs, et le deuxième type à un ensemble labellé de valeurs quelconques (elle peuvent donc aussi être imbriquées).

La figure 1 donne un exemple de représentation arborescente d’une imbrication de collection. Les nœuds internes de l’arbre sont des collections et les feuilles de cet arbre correspondent aux éléments scalaires de la

T.0.0 T.0.1 T.1.0 T.1.1 T.2.0 T.2.1 3 4 5 6 1 2 T.0 T.1 T.2 T = {{1, 2}, {3, 4}, {5, 6}} 2 3

ieme cardinal collection

la geometrie de T est int[3][2]

de la collection T.2 valeurs scalaires

niveau d’imbrication croissant

Fig. 1 –La géométrie des collections imbriquées homogènes en 81/2

collection. Cette représentation permet de définir la dimension d’une collection dont la valeur est égale à la profondeur de l’arbre qui lui est associé, moins un. On appelle rang d’une collection, la liste des nombres de fils d’un nœud à chaque niveau. Par exemple, la collection :

{{1, 2}, {3, 4}, {5, 6}}

a une dimension égale à 2 (il y a deux niveaux d’imbrication) et le rang est égal à {3, 2} (le premier niveau comporte 3 éléments, le second niveau en comporte 2).

II.3.3

Les collections homogènes

Une collection est dite homogène si toutes les régions de l’espace définies par ses imbrications sont semblables. Autrement dit, les éléments d’une collection homogène ont tous la même dimension ; si l’on considère la collection homogène comme un arbre, le nombre de fils d’un nœud de l’arbre est le même pour tous les frères du nœud. La figure 2 est un exemple de collection homogène et de collection non-homogène (une collection non-homogène est dite hétérogène). Pour simplifier, on considère qu’une collection homogène correspond à un tableau (à laC).

Le type d’une collection homogène en 81/2consiste en la définition du type scalaire de ses éléments

(collec-tions feuilles) ainsi que de la géométrie de la collection. Le type scalaire est un élément de {Int, Bool, . . . } ; la géométrie est une liste d’entiers positifs où la ne_{valeur représente le nombre d’éléments du n}e_niveau d’imbrication. Le nombre d’éléments dans la géométrie est le cardinal de la collection.

collection heterogene B

collection homogene A _dimension

collection A vue comme un arbre

collection B vue comme un arbre

Fig. 2 –Imbrication homogène et hétérogène de collections. La collection A est homogène car tous les éléments de A ont la même dimension et chaque élément de A a le même nombre de frères dans la structure. On peut considérer que A est un tableau. Ce n’est pas le cas de la collection B : les éléments de B n’ont pas tous la même dimension et le nombre de frères d’un élément, à un niveau donné, n’est pas constant.

Le typage des équations 81/2est implicite : on ne spécifie pas (ou au minimum) les informations de type et

de géométrie sur les collections. Toute constante scalaire peut se transformer implicitement en une collection constante. Par exemple, la constante 5 correspond à une collection homogène, de géométrie quelconque, dont la valeur en tout point est égale à 5. La géométrie d’une (collection) constante est automatiquement inférée par le compilateur quand c’est possible, c’est-à-dire quand le programme fournit suffisamment d’informations sur les géométries. Une constante scalaire permet donc de dénoter de manière uniforme plusieurs tissus constants de géométries différentes.

Dans la suite de cette section, nous allons présenter un certain nombre d’opérateurs permettant de construire des expressions. Ces opérateurs, sauf mention contraire explicite, s’appliquent uniquement à des tableaux.

II.3.3.1 L’α-extension des opérateurs scalaires

L’α-extension, notée «∧_{» , est un opérateur qui permet d’étendre une opération scalaire sur des éléments}

de type S en une opération sur des collections d’éléments de type S. L’α-extension se fait par l’application de la fonction élément par élément. Par exemple, l’expression suivante applique l’opérateur d’addition scalaire + aux deux collections en argument :

+∧{1, 2, 3}{4, 5, 6} ⇒ {5, 7, 9}

En 81/2, l’α-extension est implicite pour tous les opérateurs arithmétiques (+, ∗...), les opérateurs

rela-tionnels (<, >...), les opérateurs logiques (∧, | |...), et la conditionnelle if . . . then . . . else . . . . La notation infixe usuelle est utilisée pour les opérateurs standards. L’α-extension de l’addition des collections précédentes s’écrit alors simplement :

{1, 2, 3} + {4, 5, 6}

Les opérateurs implicitement α-étendus sont naturellement surchargés pour permettre une application à des expressions, qu’elles soient scalaires ou de géométrie quelconque.

II.3.3.2 La β-réduction

La β-réduction3_{, notée « \ », est un opérateur qui transforme une fonction f de deux variables scalaires}

en une fonction sur les collections. La fonction f est utilisée pour combiner tous les éléments d’une collection. Par exemple, dans l’expression suivante :

+_{\{1, 2, 3} ⇒ 1 + (2 + 3) ⇒ 6}

max_{\{1, 2, 3} ⇒ max(1, max(2, 3)) ⇒ 3}

l’utilisation de la β-réduction avec des opérateurs + ou max permet de sommer les éléments d’une collection et respectivement d’en sélectionner le plus grand élément.

L’ordre de réduction n’étant pas précisé, la fonction f doit être associative si l’on veut un résultat déter-ministe. En 81/2, cet ordre est dépendant de l’implémentation et il est de la responsabilité du programmeur

de n’utiliser que des fonctions associatives4_.

Si la collection est imbriquée, la β-réduction s’applique aux éléments de la première dimension. Par exemple :

max_{\ {{7, 12, 14, 8}, {16, 10, 11, 10}} ⇒ {16, 12, 14, 10}}

La β-réduction de chacun des éléments du vecteur se fera à l’aide de l’α-extension : (max_\)∧

{{7, 12, 14, 8}, {16, 10, 11, 10}} ⇒ {14, 16}

3. La β-réduction du data-parallélisme qui nous concerne ici ne doit pas être confondue avec la β-réduction du λ-calcul. 4. On laisse au lecteur le soin d’imaginer les différents résultats de la β-réduction d’une collection par un opérateur de division.

II.3.3.3 L’opération de balayage ou scan

La β-réduction se généralise grâce à l’opérateur de balayage noté « \\ » : cet opérateur permet de calculer une collection dont le ie_{élément a pour valeur la réduction des i}es_{premiers éléments de la collection. Par} exemple, sur des collections de dimension 1 (des vecteurs) :

+\\ {1, 1, 1, 1} ⇒ {1, 2, 3, 4} max\\ {1, 3, 2, 4} ⇒ {1, 3, 3, 4}

et, sur une collection de dimension 2 : max_\\    { 7, 12, 14, 8_} { 16, 10, 11, 10 } { 1, 2, 3, 20}    ⇒    { 7, 12, 14, 8_} { 16, 12, 14, 10 } { 16, 12, 14, 20 }   

II.3.3.4 Coupure et extension d’une collection

L’opérateur de coupure et d’extension « : [ ] » permet d’étendre et de restreindre les dimensions d’une collection. L’expression e : [c1, . . . , cn] permet de modifier le nombre d’éléments dans chacune des dimensions,

par troncature ou réplication. Le terme [c1, . . . , cn] représente le rang du résultat. Par exemple :

A _{≡ {1, 2, 3, 4}}

B _{≡ {{1, 2}, {3, 4}, {5, 6}}} alors :

A : [2] _{⇒ {1, 2}}

B : [2, 3] _{⇒ {{1, 2, 1}, {3, 4, 3}}}

II.3.3.5 La concaténation des collections

L’opérateur de concaténation, noté « #n » permet de concaténer deux collections en les mettant « bout

à bout » suivant la ne _{dimension (on abrège les opérateurs « #0 » et « #1 » respectivement par « # » et} « #b ». Par exemple, la concaténation des expressions A et B suivantes :

A _≡  {1, 1, 1} {2, 2, 2}  B _≡  {3, 3, 3} {4, 4, 4} 

suivant la première dimension a pour résultat :

A #0B ⇒        {1, 1, 1} {2, 2, 2} {3, 3, 3} {4, 4, 4}        et suivant la seconde dimension :

A #1B ⇒



{1, 1, 1, 3, 3, 3} {2, 2, 2, 4, 4, 4}

II.3.3.6 La sélection

Il est possible d’accéder à la valeur d’un point d’une collection (homogène ou hétérogène) grâce à l’opéra-teur de sélection qui se note « e  n » où e est une collection et n un entier positif. L’indexation des collections commence à 0. Par exemple, pour A = {{1, 2}, {3, 4}} :

A  0 ⇒ {1, 2}

A  1 ⇒ {3, 4}

A  2 ⇒ opération invalide car elle correspond à un accès « en dehors des bornes »

A  0  1 ⇒ 2

II.3.3.7 La permutation généralisée

L’opérateur de permutation permet de ré-ordonner les éléments d’une collection suivant les indices d’une autre collection. Soit A = {1, 2, 3, 4, 5, 6} une collection et I = {0, 0, 2, 1} la collection des indices des éléments à sélectionner dans A. Alors :

A(I) ⇒ {1, 1, 3, 2}

et ∀i ∈ [0, 5], A(I)  i = A  (I  i). La permutation se note avec des parenthèses. Voici un autre exemple où les éléments de I ne sélectionnent pas des scalaires, mais des collections. Si B = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}}, alors

B(I) _{⇒ {{1, 2, 3}, {1, 2, 3}, {7, 8, 9}, {4, 5, 6}}}

L’opération de permutation en 81/2 est plus générale : la collection des indices peut être une collection

imbriquée. Par exemple :

J = _{{{0, 1}, {2, 0}}}

A(J) _{⇒ {{1, 2}, {3, 1}}}

B(J) _{⇒ {{{1, 2, 3}, {4, 5, 6}}, {{7, 8, 9}, {1, 2, 3}}}}

II.3.3.8 L’opérateur iota

L’opérateur iota5 _{est noté «} ′ _{» en 8}

1/2. Si l’opérateur iota a pour argument un entier, alors le résultat

d’une expression ′_{n est la collection des 0 à n}

− 1 premiers entiers. Dans le cas où on applique cet opérateur à une collection (on parle alors de l’opérateur iota généralisé), celui-ci retourne la collection des indices correspondant à la géométrie de l’argument. Si on parle en termes de coordonnées d’un point pour désigner la suite des indices permettant d’accéder à un point, alors l’opérateur iota permet de construire la collection des coordonnées.

L’utilisation conjointe des opérateurs iota et de permutation permet d’effectuer le décalage des éléments d’une collection. Par exemple,′_A+

{{{1, 0}}} est une collection qui indice les voisins nord de A, en considérant la direction nord comme la direction où l’indice i d’un élément de position (i, j) est décrémentée. Une sélection de A suivant cette collection permet de décaler la collection A dans le sens des lignes décroissante (correspondant à un décalage vers le « nord » dans un voisinage NEWS), c’est-à-dire de construire la collection où tous les éléments occupent une position au « nord » de leur position initiale dans A.

II.3.4

Les collections hétérogènes : les systèmes

Un système est une collection d’éléments nommés. Par exemple, l’expression suivante :

A _{≡ {a = 1, b = {2, 2}}}

définit une collection de deux éléments, dont le premier élément a pour valeur la collection constante 1 et le second élément a pour valeur la collection {2, 2}. On peut maintenant accéder aux éléments de cette collection, de façon classique, par une position :

A  0 ⇒ 1

A  1 ⇒ {2, 2}

mais aussi par l’identificateur qui est attaché à la définition :

A  a ⇒ 1

A  b ⇒ {2, 2}

Par ailleurs, on assimile une collection hétérogène à un système en utilisant un mécanisme de nommage implicite : chaque élément d’une collection hétérogène est identifié par sa position. Ainsi, l’expression :

{1, {2, 2}}

est une collection qui n’est pas un tableau car ses éléments sont de types différents. Cette collection est un système, l’identificateur du premier élément étant le label numérique 0, l’identificateur du second élément étant le label 1. On surcharge naturellement les opérateurs de concaténation, de définition (les accolades) et de sélection, afin de faciliter l’écriture d’expressions impliquant les systèmes et les tableaux.

Le nommage des éléments d’un système ressemble à une équation en 81/2: en fait, c’est une équation

81/2. Par exemple, le système :

{a = 1, b = {a + 1, a + 1}} s’évalue en :

{a = 1, b = {2, 2}}

Un système correspond donc à un paquet d’équations et permet de structurer le code 81/2.

II.4 Combinaison de collections et de streams : le tissu 8

La programmation en 81/2se fait à travers une structure de données unique, le tissu. Un tissu est :

– soit un stream dont la valeur instantanée est une collection homogène, dont la géométrie est indépen-dante de l’instant considéré,

– soit un système dont les éléments sont des streams.

Ces deux aspects étaient plus ou moins confondus dans [Gia91a]. En effet, on peut remarquer que :

– un stream de collections homogènes peut se voir comme une collection de streams (un stream par élément) qui ont tous la même horloge,

– une collection homogène est un cas particulier de collection hétérogène (grâce au schéma de nommage implicite).

Pour le moment, nous maintiendrons une claire distinction entre les notions de tableau et de système. Dans le chapitre suivant, nous décrivons quelques exemples d’expressions 81/2.

Exemples d’expressions 8

1/2

Dans le chapitre précédent nous avons décrit rapidement le langage déclaratif 81/2. Nous décrivons dans

ce chapitre des exemples de programmes 81/2naturellement orientés vers des applications de simulation et

par conséquent la manipulation d’espaces. Le plan de ce chapitre est le suivant :

– Le premier exemple (cf. section III.1) décrit la simulation d’un système réactif dont les niveaux internes varient au cours du temps.

– Le second exemple (cf. section III.2) correspond à une implémentation en 81/2d’équations différentielles

couplées sur un réseau : le modèle chimique de diffusion–réaction d’A. Turing développé initialement pour tenter d’expliquer la formation de motifs dans un substrat homogène.

– Nous modélisons ensuite un phénomène de croissance simple, celui de la coquille d’un mollusque (cf. sec-tion III.3). Ce phénomène de croissance, discrétisé dans l’espace et dans le temps, utilise une collecsec-tion support de dimension suffisante pour représenter les étapes successives de la simulation.

– Enfin, nous montrons la capacité du langage 81/2à définir récursivement des structures de données (cf.

section III.4).

Tous les exemples décrit dans ce chapitre ont été implémentés et exécutés dans un environnement 81/2

permettant la compilation des équations [MGS94, Mic96a]. Nous avons intégré à l’environnement d’exécution des programmes 81/2une liaison avec un outil de tracé graphique, le logicielGnuplot[WKC+90]. Cette interface est décrite dans l’annexe D.

III.1 Le wlumf

Nous souhaitons décrire un système réactif particulier, un « wlumf » [Leg91] : c’est une créature artificielle dont le comportement, qui consiste principalement à manger, est régulé par le niveau de certains états internes (on se référera à [Mae91] pour un tel modèle dans le cadre de la simulation en éthologie).

Plus précisément, un wlumf est affamé quand sa glycémie est inférieure à une valeur limginf. D’autre part,

il peut manger s’il dispose de nourriture dans son environnement (les valeurs des variables de l’environnement changent de façon aléatoire). Le métabolisme du wlumf est tel que quand il mange, sa glycémie atteint la valeur limgsup, puis décroît jusqu’à zéro à une vitesse de decGpar unité de temps. Au début de la simulation,

le wlumf a une glycémie égale à initG. Toutes les variables décrivant le comportement du wlumf sont scalaires.

Essentiellement, le wlumf est constitué de compteurs et de bascules qui sont déclenchés et ré-initialisés à des vitesses différentes. La définition du wlumf consiste en deux définitions ; un environnement, où sont définis un tissu entier cpt qui représente un compteur, incrémenté avec une probabilité de 0.5 et un tissu booléen nourriture qui à une valeur vraie quand cpt est un multiple de 2 :

env =_{

cpt = $cpt + 1 when(Clock_{−2); cpt@0 = 0;}

boolean nourriture = 0 == (cpt%2);_}

Ces définitions sont utilisées par la définition du wlumf :

wlumf ={

af f ame = (glucose < 3);

af f ame@0 = false;

glucose = if mange then 10 else max(0, $glucose− 1) when Clock;

glucose@0 = 6;

mange = $af f ame && env  nourriture;

mange@0 = f alse;_}

où le système wlumf définit : le tissu booléen affame qui a une valeur vraie quand la valeur du tissu glucose passe en dessous d’un seuil limite ; le tissu entier glucose qui a pour valeur la glycémie du wlumf à un instant donné et enfin le tissu booléen mange qui a une valeur vraie quand le wlumf est affamé et que de la nourriture se trouve dans son environnement (cf. figure 1).

0 2 4 6 8 10 12 14 0 20 40 60 80 100 120 140 160 Je mange Glycémie Nourriture dans le voisinage Je suis affamé

(a) Une première évaluation

0 2 4 6 8 10 12 14 0 20 40 60 80 100 120 140 160 Je mange Glycémie Nourriture dans le voisinage Je suis affamé

(b) Une évaluation avec des initialisations différentes

Fig. 1 – Comportement d’un système dynamique hybride. Simulation du comportement d’un « wlumf »

dans des environnements où les valeurs initiales sont différentes.

III.2 L’équation de diffusion–réaction d’A. Turing

Nous donnons ici un exemple d’équations différentielles couplées sur un réseau, exemple correspondant à la deuxième colonne dans la classification donnée table 1 de la page 4.

Le mathématicien A. Turing souhaitait savoir si la forme des taches sur un pelage d’animal pouvaient avoir une origine autre que génétique. Son modèle montre que des taches réalistes peuvent être produites comme le résultat d’un processus ne faisant pas intervenir de matériel génétique. Il a proposé un modèle de réaction chimique pour expliquer la formation de motifs, comme le résultat de concentrations de certaines substances chimiques, dans un milieu initialement homogène. Turing appelle ces agents chimiques des morphogènes [Tur52] et le modèle de réaction chimique, le modèle de diffusion–réaction. La forme générale des équations de Turing est [Tur91] :

3.85 3.9 3.95 4 4.05 4.1 4.15 0 10 20 30 40 50 60 Concentration

(a) État du système après 100 pas de simulation

0 1 2 3 4 5 6 7 8 9 0 10 20 30 40 50 60 Concentration

(b) État du système après 1000 pas de simulation

Fig. 2 –Équation de diffusion–réaction dans un tore, d’après A. Turing. Le résultat de la simulation est représenté après 100 pas de temps élémentaires (figure (a)), et après 1000 pas de temps, alors que le phénomène décrit par le système dynamique est stabilisé (figure (b)). La variation constatée peut correspondre à une quantité de colorant et le résultat peut s’interpréter comme des taches périodiquement disposées le long du tore. ∂x ∂t = F (x, y) + Dx∇ 2_x ∂y ∂t = G(x, y) + Dy∇ 2_y

où les équations définissent que le changement de concentration pour un morphogène x à un instant t dépend d’une fonction F des concentrations locales des morphogènes x et y et d’un processus de diffusion de x. La constante Dx exprime la vitesse de diffusion du morphogène x et ∇2x est une mesure de la variation de la

concentration de x par rapport à ses voisins. Depuis l’introduction de ces idées, de nombreux systèmes ont été étudiés afin de mettre en évidence l’action de morphogènes dans un processus de diffusion–réaction lors de l’apparition de motifs.

Par exemple, le système différentiel de départ [BL74] qui gouverne l’état de la cellule r est : ∆xr dt = 1 16(16− xryr) + (xr+1− 2xr+ xr−1) (1) ∆yr dt = 1 16(xryr− yr− β) + (yr+1− 2yr+ yr−1) (2)

où x et y représentent deux espèces chimiques en réaction, diffusant sur un tore de cellules indexées par r. Dans ce modèle, le temps de la réaction chimique est continu alors que l’espace de la diffusion correspond à l’espace discret des cellules. La programmation en 81/2de ce modèle utilise bien sûr l’aspect stream d’un

tissu pour représenter le temps et l’aspect collection pour représenter l’espace des cellules. Le programme 81/2est le suivant :

iota = ′_60;

droite = if(iota == 0) then 59 else(iota_{− 1);} gauche = if(iota == 59) then 0 else(iota + 1);

rsp = 1.0/16.0;

dif f 1 = 0.25;