Auteurs PaulKenji Cahier Sylvain Mah Pr Soutenance de

  • Slides: 21
Download presentation
Auteurs: Paul-Kenji Cahier Sylvain Mahé Pré Soutenance de TER Année 2004 -2005 Laurent Toselli

Auteurs: Paul-Kenji Cahier Sylvain Mahé Pré Soutenance de TER Année 2004 -2005 Laurent Toselli Conception de Programmes Evolutifs Encadrants : Cathy Escazut et Michel Gautero

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. –

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. – Programmation statique vs programmation évolutive. – Présentation du projet. • Détails de l’application (5 min. ) – Moteur de sélection. – Application graphique. • Risques (4 min. ) • Planification (4 min. ) • Questions ( le temps restant )

Introduction • Problème qui nous a amené à ce TER: – Existe-il des programmes

Introduction • Problème qui nous a amené à ce TER: – Existe-il des programmes s’auto modifiant qui sont codés une fois pour toute ? • Réponse négative à notre connaissance. • Réponse positive pour une fonction de la sorte – fam : fonction auto modifiante » (define (fam x) » (let ((g (lambda (x) (* k x)))) » (define (modifg) » . » . » ) » (define (iter) » (if (not (= (g x) y)) » (modifg) » g)) » (iter)) – Modifie de la fonction g mais son aspect reste globalement le même à l’intérieur de la fonction f.

Introduction (suite) – On est dans une approche « fermée » de l’auto modification

Introduction (suite) – On est dans une approche « fermée » de l’auto modification (dépendant du problème). – D’où utilisé pour des cas particuliers cependant. – Notre application générera du code n’ayant peut-être aucun rapport avec le code précédent. On est dans une approche « ouverte » (indépendant du problème). • Le cas général sera présenté dans notre projet avec une application représentant un cas particulier.

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. –

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. – Programmation statique vs programmation évolutive. – Présentation du projet. • Détails de l’application (5 min. ) – Moteur de sélection. – Application graphique. • Risques (4 min. ) • Planification (4 min. ) • Questions ( le temps restant )

programmes statiques Vs. programmes évolutifs. – Les programmes classiques , en général, ne sont

programmes statiques Vs. programmes évolutifs. – Les programmes classiques , en général, ne sont pas vus pour être modifiés après compilation. – La modification de code à l’extérieur du programme (finalisé) n’est pas possible. – D’où notion de patchs correctifs (en cas de bogue). – Intérêt de notre part de trouver un mécanisme. – Programmes évolutifs : • Programmes dynamiques. (fam vues précédemment) • Programmes 2 en 1. – Modification et exécution du programme non dissocié. – Pas d’idées pour le moment, pas de connaissances à ce sujet. • Projet TER (notre proposition ) – Donc un choix de la représentation des programmes personnalisée pour obtenir cette capacité. – Modification possible des programmes sans que l’idée soit changée et en temps réel.

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. –

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. – Programmation statique vs programmation évolutive. – Présentation du projet. • Détails de l’application (5 min. ) – Moteur de sélection. – Application graphique. • Risques (4 min. ) • Planification (4 min. ) • Questions ( le temps restant )

Projet de colonie de fourmis. – Simulation de comportement de fourmis dans un certain

Projet de colonie de fourmis. – Simulation de comportement de fourmis dans un certain environnement. – Un seul caste de fourmis au départ (ouvrière). – Actions de base (fonctions de base) permises pour chaque fourmis : • • Chercher de la nourriture. Déplacement. Faire face à une attaque de prédateur (extension) … – Visibilité via une interface graphique : • • Suivi du comportement global des fourmis. Obtention d’informations sur l’une d’entre elles. Modifications de paramètres (extension). Génération de programme à l’instant t. (lié au moteur)

Projet de colonie de fourmis. – Extensions: • Prédateurs (araignées) • Fourmilière(s) • Classe

Projet de colonie de fourmis. – Extensions: • Prédateurs (araignées) • Fourmilière(s) • Classe (> 1) de fourmis (ouvrière, soldat, nurse, reine, princesse, réserve fourmilière (à miel), …) • Notion d’ordres dans les besoins d’une fourmi. • Classeur d’a. g. sur 2 niveaux (suivre l’héritage entre générations) ? • Environnement changeant. ( utilisation des règles d’inférences ) ? • Une fourmilière codé statiquement face à une autre évolutive ?

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. –

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. – Programmation statique vs programmation évolutive. – Présentation du projet. • Détails de l’application (5 min. ) – Moteur de sélection. – Application graphique. • Risques (4 min. ) • Planification (4 min. ) • Questions ( le temps restant )

Moteur de sélection – Composition du moteur général: • moteur d’inférences • algorithmes génétiques

Moteur de sélection – Composition du moteur général: • moteur d’inférences • algorithmes génétiques (générateur de classeurs). • Sélection d’un classeur = algorithmes appartenant à une même classe de problèmes – ( « déplacement » , « cher nourriture » , « cher quelqu’un » , …) – Vue sur les règles d’inférences: • Ensemble de règles de type env -> action (fonctions de base) appelées classeur • Ensemble de règles de type action -> ‘algon’. • Les algorithmes génétiques, évolution : – – Trouver des règles plus convenables pour une fourmi dans un certain environnement. Re-génération de nouveaux classeurs. Possibilité d’avoir plusieurs actions pour un environnement. Le moteur d’inférences se charge de calculer la liste des algorithmes possibles. – Choix de l’algorithme pour la fourmi parmi ceux retenues.

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. –

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. – Programmation statique vs programmation évolutive. – Présentation du projet. • Détails de l’application (5 min. ) – Moteur de sélection. – Application graphique. • Risques (4 min. ) • Planification (4 min. ) • Questions ( le temps restant )

Application graphique • Écrit en langage java: – Portabilité du projet – Confirmer la

Application graphique • Écrit en langage java: – Portabilité du projet – Confirmer la capacité du moteur à rester indifférent aux langages de l’application. – Interface graphique en Java 2 D avec possible extension en Java 3 D via JOGL • Liaison entre application et moteur – – Le moteur est en scheme et est converti en C via Chicken/Stalin Il est compile sous forme de librairie ensuite liee au java via JNI Combinaison permet de garder une bonne vitesse sur le partie Scheme qui sera tres solicite Pourquoi pas Bigloo? Bigloo ne gere pas call-cc et bigloo serait trop lent pour un moteur qui risque d’etre appele plusieurs dizaines de fois par seconde.

Application graphique • Detail de l’application – – • Chaque fourmi est visionable pour

Application graphique • Detail de l’application – – • Chaque fourmi est visionable pour voir ses specificites La fenetre principale presente la vue d’ensemble de la fourmiliere Certaines interactions sont possibles (uniquement a desseins d’experience) Au debut de l’application la fourmiliere est cree, ainsi que l’environement, puis on fait appel au moteur scheme a chaque fois qu’une fourmi a besoin de prendre une decision (ie a fini d’executer une action) Portabilite – A cause des JNI l’execution ne peut se faire dans un applet, et elle requiert des binaires differents pour chaque architecture – Le code reste aisement portable de par sa nature, c’est a dire generee depuis le scheme/java

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. –

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. – Programmation statique vs programmation évolutive. – Présentation du projet. • Détails de l’application (5 min. ) – Moteur de sélection. – Application graphique. • Risques (4 min. ) • Planification (4 min. ) • Questions ( le temps restant )

Risques • Défaut de conception du moteur sélection (moteur inférences + système de classeurs):

Risques • Défaut de conception du moteur sélection (moteur inférences + système de classeurs): – Trouver la bonne représentation des classeurs pour les faire interagir avec le moteur d’inférence. • • • Défaut de liaison moteur sélection/GUI Divers problèmes liés aux systèmes d’exploitations. GUI : – Lenteur de l’interface. – Le nombre de fourmis à gérer ne doit pas ralentir l’application. – Environnement dynamique dans l’extension pour simplifier les capacités de gestion et d’altération dans l’environnement.

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. –

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. – Programmation statique vs programmation évolutive. – Présentation du projet. • Détails de l’application (5 min. ) – Moteur de sélection. – Application graphique. • Risques (4 min. ) • Planification (4 min. ) • Questions ( le temps restant )

Planification

Planification

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. –

Sommaire • Introduction (4 min. ) – Direction donnée par des problèmes rencontrés. – Programmation statique vs programmation évolutive. – Présentation du projet. • Détails de l’application (5 min. ) – Moteur de sélection. – Application graphique. • Risques (4 min. ) • Planification (4 min. ) • Questions ( le temps restant )

Questions • Model Environnement ? • Classeur = fourmis ? • …

Questions • Model Environnement ? • Classeur = fourmis ? • …