Conception de Programmes Evolutifs

1
Conception de Programmes Evolutifs

• Pré Soutenance de TER
• Année 2004-2005

Auteurs Paul-Kenji Cahier Sylvain Mahé Laurent
Toselli
Encadrants Cathy Escazut
et Michel Gautero
2
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 lapplication (5 min.)
• Moteur de sélection.
• Application graphique.
• Risques (4 min.)
• Planification (4 min.)
• Questions ( le temps restant ?)

3
Introduction

• Problème qui nous a amené à ce TER
• Existe-il des programmes sauto 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)

4
Introduction (suite)

• On est dans une approche fermée de lauto
  modification (dépendant du problème).
• Doù utilisé pour des cas particuliers cependant.
• Notre application générera du code nayant
  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 applicationreprésentant un cas
  particulier.

5
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 lapplication (5 min.)
• Moteur de sélection.
• Application graphique.
• Risques (4 min.)
• Planification (4 min.)
• Questions ( le temps restant ?)

6
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 à lextérieur du
  programme (finalisé) nest pas possible.
• Doù 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 didé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
  lidée soit changée et en temps réel.

7
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 lapplication (5 min.)
• Moteur de sélection.
• Application graphique.
• Risques (4 min.)
• Planification (4 min.)
• Questions ( le temps restant ?)

8
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 dinformations sur lune dentre elles.
  
• Modifications de paramètres (extension).
• Génération de programme à linstant t. (lié au
  moteur)

9
Projet de colonie de fourmis.

• Extensions
• Prédateurs (araignées)
• Fourmilière(s)
• Classe (gt 1) de fourmis (ouvrière, soldat, nurse,
  reine, princesse, réserve fourmilière (à miel),
  )
• Notion dordres dans les besoins dune fourmi.
• Classeur da.g. sur 2 niveaux (suivre lhéritage
  entre générations) ?
• Environnement changeant.( utilisation des règles
  dinférences ) ?
• Une fourmilière codé statiquement face à une
  autre évolutive ?

10
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 lapplication (5 min.)
• Moteur de sélection.
• Application graphique.
• Risques (4 min.)
• Planification (4 min.)
• Questions ( le temps restant ?)

11
Moteur de sélection

• Composition du moteur général
• moteur dinférences
• algorithmes génétiques (générateur de classeurs).
• Sélection dun classeur algorithmes
  appartenant à une même classe de problèmes
• ( déplacement , chercher nourriture ,
  chercher quelquun , )
• Vue sur les règles dinférences
• Ensemble de règles de type env -gt action
  (fonctions de base) appelées classeur
• Ensemble de règles de type action -gt 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é davoir plusieurs actions pour un
  environnement.
• Le moteur dinférences se charge de calculer la
  listedes algorithmes possibles.
• Choix de lalgorithme pour la fourmi parmi ceux
  retenues.

12
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 lapplication (5 min.)
• Moteur de sélection.
• Application graphique.
• Risques (4 min.)
• Planification (4 min.)
• Questions ( le temps restant ?)

13
Application graphique

• Écrit en langage java
• Portabilité du projet
• Confirmer la capacité du moteur à rester
  indifférent aux langages de lapplication.
• Interface graphique en Java 2D avec possible
  extension en Java 3D via JOGL
• Liaison entre application et moteur
• Le moteur est en scheme et est interprete
  dynamiquement via SISC
• Le code est dabord micro compile par SISC puis
  execute
• SISC permet de garder le cote scheme directement
  et simplement interprete a vitesse raisonnable
• Pourquoi pas Bigloo? Bigloo ne gere pas call-cc

14
Application graphique

• Detail de lapplication
• Chaque fourmi est visionable pour voir ses
  specificites
• La fenetre principale presente la vue densemble
  de la fourmiliere
• Certaines interactions sont possibles (uniquement
  a des desseins dexperience)
• Au debut de lapplication la fourmiliere est
  cree, ainsi que lenvironement, puis on fait
  appel au moteur scheme a chaque fois quune
  fourmi a besoin de prendre une decision (ie a
  fini dexecuter une action)
• Il est possible a tout moment de sauvegarder
  letat actuel de la fourmiliere
• Portabilite
• Le moteur reste entirement multi-plateforme grace
  a java et SISC, et fonctionne meme sous forme
  dapplet

15
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 lapplication (5 min.)
• Moteur de sélection.
• Application graphique.
• Risques (4 min.)
• Planification (4 min.)
• Questions ( le temps restant ?)

16
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
  dinférence.
• Défaut de liaison moteur sélection/GUI
• Divers problèmes liés aux systèmes
  dexploitations.
• GUI
• Lenteur de linterface.
• Le nombre de fourmis à gérer ne doit pas ralentir
  lapplication.
• Environnement dynamique dans lextension pour
  simplifier les capacités de gestion et
  daltération dans lenvironnement.

17
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 lapplication (5 min.)
• Moteur de sélection.
• Application graphique.
• Risques (4 min.)
• Planification (4 min.)
• Questions ( le temps restant ?)

18
Planification
19
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 lapplication (5 min.)
• Moteur de sélection.
• Application graphique.
• Risques (4 min.)
• Planification (4 min.)
• Questions ( le temps restant ?)

20
Questions

• Model Environnement ?
• Classeur fourmis ?

21
Conception de programmes évolutifs
That's all folks