Titre du Sujet
Quatre sujets autour des Machines à signaux :- pilotes d'exportation pdf, jpg et animations,
- interface graphique,
- langage pour manipulation de machines à signaux, et
- espace de dimension 2 et visualisation en 3D.
Nom(s) du (des) responsables
Jérôme DURAND-LOSEAdresse, Tél, courrier-E
jerome.durand-lose@univ-orleans.fr Laboratoire d'Informatique Fondamentale d'Orléans Université d'Orléans Bâtiment IIIA Rue Léonard de Vinci B.P. 6759 F-45067 ORLÉANS Cedex 2 tel : 00 33 0 238 41 73 18 fax : 00 33 0 238 41 71 37
Description du travail souhaité
Briévement
Un petit logiciel en java pour simuler des machines à signaux et faire de jolis dessins a été écrit et de nouvelles fonctionnalités sont souhaitées.
Le sujet « écriture de pilotes » n'est pas très complexe mais permet de manipuler différentes formats de sortie (il devrait exister des bibliothèques pour cela).
La création d'une interface graphique est assez classique et sans réelle difficulté.
Les deux autres sujets sont beaucoup plus ambitieux, l'un demandant de définir puis d'implanter un langage spécifique, l'autre demandant de travailler au niveau d'un noyau de logiciel puis faire un pilote de sortie.
Fig. 1 : Exemple de diagramme espace-temps.
Plus précisément
Depuis un lustre (hé oui, cela ne fait pas encore des lustres), dans le cadre du collision computing et de l'abstract geometrical computation j'ai développé un modèle de calcul basé sur la propagation de signaux sans dimension dans un espace euclidien, en particulier la droite réelle. Une « machine à signaux » se définit par un nombre fini de méta-signaux et des règles de collision. Pour démarrer un calcul, on dispose des signaux sur la droite. Ceux-ci se déplacent de manière uniforme (et forment donc des segments de droite sur le diagramme espace-temps). Quand des signaux se rencontrent, ils disparaissent et sont remplacés par d'autres en suivant les règles de la machine.
Bien qu'il ne soit pas nécessaire, pour le TER, de comprendre comment (ni même ce que cela veut dire), signalons que les machines à signaux sont capables de simuler toute machine de Turing, d'émuler le modèle du Trou noir... et que l'on peut y implanter des modèles de calcul analogiques ainsi que des primitives géométriques...
Fig. 2 : Autre exemple.
Le modèle s'implante sur ordinateur (cela a été fait en java) en ne considérant que des positions et des vitesses rationnelles (ce qui permet une représentation exacte avec une bibliothèque idoine). Cette implantation a permis, en plus d'expérimenter et de produire beaucoup d'illustrations, de tester et de valider différents résultats.
Le but de ces TER est d'ajouter des fonctionnalités à et autour de ce logiciel.
Actuellement, les seules sorties sont en postcript encapsulé (.eps) ou en LaTeX (.tex). Le premier sujet est d'ajouter d'autres types de sortie, en particulier portable document format (.pdf), un format image (.jpg ou autre) et un format d'animation (.mpeg ou autre). Le but des animations est de pouvoir, d'une part voir apparaître un diagramme espace-temps progressivement et, d'autre part pouvoir enchaîner différents diagrammes (p.e. quand on fait varier la position des signaux initiaux).
Actuellement, il n'existe pas franchement d'interface. On peut écrire du code Java ad hoc, charger des fichiers XML ou produire des machines à partir d'autres modèles (p.e. machines de Turing). Le but de ce sujet est la réalisation d'une interface graphique permettant de définir des méta-signaux, des règles de collisions, des configurations initiales, de les charger et de les sauvegarder en XML, d'engendrer des diagrammes espace-temps, et de les exporter dans différents formats.
Différentes façons de construire une machine à partir d'une autre pour obtenir un effet particulier ont été développées. À chaque fois, il a fallu implanter une classe Java particulière. Il serait beaucoup plus simple de pouvoir définir comment engendrer une machine à partir d'une autre dans un langage externe. Le but de ce sujet est de proposer un langage simple dédié à cela. Une fois le langage défini, il faudrait réaliser un compilateur qui le transforme en la classe Java correspondante.
Tout ce qui a été développé ne marche qu'en dimension 1 même si tout se passe identiquement en dimension 2 et supérieure. Le passage en dimension 2 pose deux problèmes : le noyau et l'affichage. Le noyau du logiciel tire partie du fait que l'on est en dimension 1 et l'algorithme ne passe pas en dimension supérieure où il faut utiliser des algorithmes et structures de données particulières. L'affichage est aussi problématique car avec la dimension temporelle en plus, il faut faire un affichage en 3D ou une animation. Et soyons rêveur, on pourrait même imaginer aller jusqu'à un affichage et un mode d'utilisation/navigation en réalité virtuelle.
Fig. 3 : Exemple plus complexe.
Moyens matériels et logiciels nécessaires
L'existant a été développé en Java sous Eclipse.
Il n'est pas nécessaire d'avoir une grande puissance de calcul et un ordinateur portable suffit.
En plus, selon le cas, des connaissances en compilation ou en algorithmique peuvent être nécessaires.
Pour les pilotes comme pour la 3D, si nécessaire l'auto-apprentissage rapide des bibliothèques concernées sera à faire au démarrage du projet.
Références bibliographiques et http
Publications où l'on peut trouver nombre d'illustrations des machines à signaux : http://www.univ-orleans.fr/lifo/Members/Jerome.Durand-Lose/Recherche/publications.html (regarder rapidement les pdf et les exposés des conférences).