La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 © Jérôme Lehuen - Université du Maine - 03/10/01 Représentation des connaissances –Représentation des faits –Représentation des règles –Programmation.

Présentations similaires


Présentation au sujet: "1 © Jérôme Lehuen - Université du Maine - 03/10/01 Représentation des connaissances –Représentation des faits –Représentation des règles –Programmation."— Transcription de la présentation:

1 1 © Jérôme Lehuen - Université du Maine - 03/10/01 Représentation des connaissances –Représentation des faits –Représentation des règles –Programmation fonctionnelle Moteur dinférences –Compilation de la base de règles –Stratégies de résolution de conflits Systèmes à Base de Connaissances Le système CLIPS Ce document nest pas un manuel de référence mais un support de cours La documentation CLIPS est téléchargeable sur le site web suivant :

2 2 © Jérôme Lehuen - Université du Maine - 03/10/01 Rappels Problématique : –Pas toujours facile (ni même possible) dexprimer la manière de résoudre un problème en décrivant un algorithme –On cherche à simuler le raisonnement humain dans les domaines où les connaissances sont évolutives et dans lequel il nexiste pas de méthode sûre ou déterministe : –Exemple de la finance, de léconomie, des sciences sociales –Exemple de la médecine (diagnostic médical), de la maintenance –Exemple de la démonstration automatique de théorèmes, … Méthode : –Isoler et modéliser un sous-ensemble du monde réel –Poser le problème en termes de faits initiaux ou de but à atteindre –Lancer un programme qui simule le raisonnement humain

3 3 © Jérôme Lehuen - Université du Maine - 03/10/01 Connaissances dun SBC Partie déclarative : – Fait : connaissance déclarative (information) sur le monde réel – Règle : connaissance déclarative de gestion de la base de faits –En logique monotone : uniquement ajouts de faits –En logique non-monotone : ajouts, modifications et retraits de faits Partie algorithmique : – Moteur dinférences : composant logiciel qui effectue des raisonnements sur la connaissance déclarative dont il dispose : –Applique les règles de la base de règles aux faits de la base de faits –Fondé sur une ou plusieurs règles dinférences (ex : déduction) –La trace du raisonnement peut être consultée : Durant les phases de conception ou de débuggage Pour obtenir des explications sur la résolution

4 4 © Jérôme Lehuen - Université du Maine - 03/10/01 RèglesFaits Architecture dun SBC Base de faits : Contient les faits initiaux, puis les faits déduits Base de règles : Contient les règles qui exploitent les faits Moteur dinférences : Applique les règles aux faits ajouts / modifications / suppressions règles dinférence faits initiaux règles du domaine autres actions

5 5 © Jérôme Lehuen - Université du Maine - 03/10/01 Exemple de la déduction Modus PonensModus Tollens (homme Socrate) est vrai (homme Socrate) (mortel Socrate) (mortel Socrate) est vrai (mortel McLeod) est faux (homme McLeod) (mortel McLeod) (homme McLeod) est faux (homme Socrate) est vrai (homme ?x) (mortel ?x) Substs : { ?x = Socrate } (mortel Socrate) est vrai (mortel McLeod) est faux (homme ?x) (mortel ?x) Substs : { ?x = McLeod } (homme McLeod) est faux Inférences sans variable : Inférences avec variables :

6 6 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

7 7 © Jérôme Lehuen - Université du Maine - 03/10/01 Le système CLIPS 6.10 Un environnement de développement complet : –Caractéristiques : –Trois formalismes de représentation des connaissances –Moteur dordre 1 fonctionnant en chaînage avant (Modus Ponens) –Implémentation en langage C de lalgorithme RETE (efficacité) –Langage de commande et de programmation de type Lisp –Modes de commande : –Mode batch (le système est lancé avec un fichier de commandes) –Mode ligne de commande (seulement pour les amateurs) –Interface graphique multi-fenêtrée (Windows, Macintosh, Unix) La cerise sur le gâteau : –Logiciel libre écrit en langage C (code lisible et documenté) –Une communauté de développeurs CLIPS plutôt active –Des sites Web, des extensions, une liste de distribution

8 8 © Jérôme Lehuen - Université du Maine - 03/10/01 Bref historique CLIPS (C-Language Integrated Production System) : –1985 : release 1.0 (prototype) –Artificial Intelligence Section Lyndon B. Johnson Space Center –Implémentation en C du moteur dinférences le plus efficace : OPS 5 –1986 : release 3.0 (première diffusion officielle) –1991 : release 5.0 (aspects procéduraux + COOL) –La couche objet sinspire de CLOS (Common Lisp Object System) –1993 : release 6.0 (modules + filtrage des objets COOL) –1998 : release 6.1 (user functions + profiler + compatibilité C++) Les « produits dérivés » : –JESS (the Java Expert System Shell) : Version Java de CLIPS –CAPE (CLIPS and Perl with Extensions) : Intégration de Perl –WebCLIPS : Version CGI pour serveurs HTTP –FuzzyCLIPS : Pour les amateurs de logique floue

9 9 © Jérôme Lehuen - Université du Maine - 03/10/01 Interface graphique

10 10 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

11 11 © Jérôme Lehuen - Université du Maine - 03/10/01 Gestion de la BDF Ajouter un fait dans la BDF : CLIPS> (assert (homme Socrate)) CLIPS> (assert (mortel Socrate)) Retirer un fait de la BDF : CLIPS> (retract 0)

12 12 © Jérôme Lehuen - Université du Maine - 03/10/01 Déduction sans variable Règle qui ajoute un fait dans la BDF : (defrule deduction-1 "Cette règle réalise un Modus Ponens sans variable" (homme Socrate) => (assert (mortel Socrate)))

13 13 © Jérôme Lehuen - Université du Maine - 03/10/01 Déduction avec variable Règle qui ajoute un fait dans la BDF : (defrule deduction-2 "Cette règle réalise un Modus Ponens avec variable" (homme ?x) => (assert (mortel ?x)))

14 14 © Jérôme Lehuen - Université du Maine - 03/10/01 Syntaxe des faits Fait ordonné ou pattern : –Liste constituée dun symbole (la relation) suivi dune séquence (éventuellement vide) de données séparées par des espaces –Une donnée doit être de lun des huit types CLIPS (voir typologie) –Un symbole est une séquence de nimporte quels caractères ASCII à lexception des caractères suivants : ( ) & $ | ; ? ~ Les faits CLIPS nacceptent pas de caractères accentués ! Exemples de patterns : (flag) (homme Socrate) (adresse Dupont "99 rue des Mésanges, Groland") (statut pompe active) (sorte-de Walibi Marsupial) (personnes Pierre Paul Jacques Marie)

15 15 © Jérôme Lehuen - Université du Maine - 03/10/01 Syntaxe des règles Constructeur de règles : –Constitué dune séquence de conditions suivie dune séquence dactions à exécuter si toutes les conditions sont vérifiées : Les filtres ou pattern-conditional elements : –Permet le filtrage des faits ou pattern-matching –Structure qui contient des constantes, des jokers et des variables : –Constante : donnée symbolique ou (alpha-) numérique –Joker ( wildcard ) : monovalué ( ? ) ou multivalué ( $? ) –Variable : monovaluée ( ?toto ) ou multivaluée ( $?toto ) (defrule [commentaire]; Chaîne de caractères *; LHS (Left-Hand Side) => *); RHS (Right-Hand Side)

16 16 © Jérôme Lehuen - Université du Maine - 03/10/01 Principe du filtrage Filtrage des faits ou pattern matching : –Consiste à comparer un filtre avec les faits de la base de faits : –Les constantes ne sont égales quà elles-mêmes –Les jokers absorbent les données rencontrées –Les variables libres sapparient aux données rencontrées –Les variables liées comparent leur valeur aux données rencontrées Exemple : –Soit la base de faits suivante : –Soient les règles suivantes : (defrule test1 (statut ?element active) =>) (defrule test3 (statut ?element ouverte) (alerte ? non) =>) (defrule test2 (statut ?element ouverte) (alerte ?element non) =>) (defrule test4 (statut $?etat) =>)

17 17 © Jérôme Lehuen - Université du Maine - 03/10/01 Règle déclenchable Définition : –Règle dont toutes les conditions (LHS) sont vérifiées –Une activation réuni une règle déclenchable et les faits concernés –Les activations sont placées dans une file appelée agenda –La règle « test1 » est déclenchable avec le fait n°1 –La règle « test1 » est déclenchable avec le fait n°4 –La règle « test3 » est déclenchable avec les faits n°2 et n°3 –La règle « test4 » est déclenchable avec le fait n°1 –La règle « test4 » est déclenchable avec le fait n°2 –La règle « test4 » est déclenchable avec le fait n°4 pompe.clp

18 18 © Jérôme Lehuen - Université du Maine - 03/10/01 Agenda de tâches - Initialiser lagenda - Tant quil reste des tâches dans lagenda : - Effectuer la première tâche - Mettre à jour lagenda : - Supprimer les tâches obsolètes - Insérer les nouvelles tâches Principe : –Maintenir une file dattente (ordonnée) dactivations RèglesFaits Rule : R034 Priority : 10 Substs : { }

19 19 © Jérôme Lehuen - Université du Maine - 03/10/01 Dépendance logique Problème de la non-monotonie : –Des faits supprimés peuvent rendre la BDF incohérente –On souhaite maintenir la cohérence logique de la BDF Solution proposée : –Décrire un graphe de dépendances entre des faits conditionnels et les faits déduits (si un fait est supprimé, cela doit pouvoir déclencher une série de suppressions en chaîne) –Les filtres avec dépendance logique doivent figurer en tête : Exemple du frigo : (defrule interrupteur "Une règle dextinction nest plus nécessaire" (logical (refrigerator door open)) => (assert (refrigerator light on)))

20 20 © Jérôme Lehuen - Université du Maine - 03/10/01 Dépendance logique Attention cest un peu plus compliqué quil ny paraît ! –Voir exemple dans le Basic Programming Guide page 55 –A utiliser avec précaution et parcimonie ! CLIPS> (assert (refrigerator door open)) ==> f-1 (refrigerator door open) ==> Activation 0 interrupteur: f-1 CLIPS> (run) FIRE interrupteur: f-1 ==> f-2 (refrigerator light on) CLIPS> (retract 1) <== f-1 (refrigerator door open) <== f-2 (refrigerator light on)

21 21 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

22 22 © Jérôme Lehuen - Université du Maine - 03/10/01 Le monde des cubes On veut écrire la partie « I.A. » dun robot mobile : –Le robot doit effectuer des actions en fonction de connaissances sur son environnement et dun but qui lui est donné –Ses actions doivent être le résultat dun raisonnement (IA) –Une action doit modifier la représentation (modèle) du monde Ce logiciel sera fondé sur une base de connaissances : –Connaissances du robot : –Connaissances sur le monde et sur lui-même –Implémentées à laide de faits stockés dans la base de faits –Raisonnement du robot : –Un but peut donner lieu à une série de sous-buts et dactions (planification) –Implémenté à laide de règles portant sur les faits

23 23 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.0 (analyse) Raisonnement de type planification : –Pour déposer un objet A sur un objet B, il faut posséder lobjet A et être à proximité de lobjet B –Pour posséder un objet, il faut prendre cet objet –Pour prendre un objet, il faut être à proximité de cet objet –Pour être à proximité dun objet, il faut aller vers cet objet Déposer A sur B Posséder A Prendre A Aller vers B Être à proximité de AAller vers A 12 but Être à proximité de B

24 24 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.0 (analyse) Les actions du robot : –Action : déposer un objet A sur un objet B –Conséquence : lobjet A est sur lobjet B –Condition : posséder lobjet A –Condition : être à proximité de lobjet B –Action : prendre un objet –Conséquence : possession de lobjet –Condition : être à proximité de lobjet –Action : aller vers un objet –Conséquence : être à proximité de lobjet

25 25 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.0 (analyse) Les règles de décomposition : –But : déposer un objet A sur un objet B –Sous-but : posséder lobjet A –Sous-but : être à proximité de lobjet B –But : posséder un objet –Sous-but : prendre lobjet –But : prendre un objet –Sous-but : être à proximité de lobjet –But : être à proximité dun objet –Sous-but : aller vers lobjet

26 26 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.0 (codage) (defrule action-deposer (but deposer ?objet1 ?objet2) (possede ?objet1) (proximite ?objet2) => (printout t "Je dépose " ?objet1 " sur " ?objet2 crlf) (assert (sur ?objet1 ?objet2))) (defrule action-prendre (but prendre ?objet) (proximite ?objet) => (printout t "Je prends " ?objet crlf) (assert (possede ?objet))) (defrule action-aller-vers (but aller-vers ?objet) => (printout t "Je vais vers " ?objet crlf) (assert (proximite ?objet)))

27 27 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.0 (codage) Règles de décomposition : Fait initial (dans la base de faits dès le début) : (deffacts init (but deposer cube-A cube-B)) (defrule decompose-deposer (but deposer ?objet1 ?objet2) => (assert (but proximite ?objet2))) (assert (but possede ?objet1))) (defrule decompose-prendre (but prendre ?objet) => (assert (but proximite ?objet))) (defrule decompose-proximite (but proximite ?objet) => (assert (but aller-vers ?objet))) (defrule decompose-possede (but possede ?objet) => (assert (but prendre ?objet)))

28 28 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.0 (tests) Chargement et exécution du code 1.0 : –Que penser de la base de faits après lexécution ? cubes1.clp

29 29 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.1 (analyse) Modification du code : –On veux supprimer les buts devenus obsolètes qui peuvent perturber le processus de planification Comment supprimer un fait dans le RHS dune règle ? –On mémorise son fact-address dans une variable –On fait un retract en lui passant ladresse du fait : (defrule... ; Mémorisation... => (retract ); Suppression... )

30 30 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.1 (codage) (defrule action-deposer ?p <- (but deposer ?objet1 ?objet2) (possede ?objet1) (proximite ?objet2) => (printout t "Je dépose " ?objet1 " sur " ?objet2 crlf) (assert (sur ?objet1 ?objet2)) (retract ?p)) (defrule action-prendre ?p <- (but prendre ?objet) (proximite ?objet) => (printout t "Je prends " ?objet crlf) (assert (possede ?objet)) (retract ?p)) (defrule action-aller-vers ?p <- (but aller-vers ?objet) => (printout t "Je vais vers " ?objet crlf) (assert (proximite ?objet)) (retract ?p))

31 31 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.1 (codage) Règles de décomposition : –Pourquoi ne pas retirer les buts des règles décompose-déposer et décompose-prendre ? (defrule decompose-deposer (but deposer ?objet1 ?objet2) => (assert (but proximite ?objet2)) (assert (but possede ?objet1))) (defrule decompose-prendre (but prendre ?objet) => (assert (but proximite ?objet))) (defrule decompose-proximite ?p <- (but proximite ?objet) => (assert (but aller-vers ?objet)) (retract ?p)) (defrule decompose-possede ?p <- (but possede ?objet) => (assert (but prendre ?objet)) (retract ?p))

32 32 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.1 (tests) Chargement et exécution du code 1.1 : –Que penser de la base de faits après lexécution ? cubes2.clp

33 33 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.2 (analyse) Encore deux bugs : –Quand le robot va vers le cube B, il reste à proximité du cube A –Quand le robot dépose le cube A, il le possède toujours Modification du code : –Il faut supprimer le fait (possede ?objet1) dans le RHS de la règle action-déposer –Il faut supprimer le fait (proximite ?) dans le RHS de la règle action-aller-vers –Que faire sil ny a pas de fait « proximité » dans le base de faits ? Tester labsence dun fait dans le LHS dune règle : –Condition dabsence : (not )

34 34 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.2 (codage) (defrule action-deposer ?p <- (but deposer ?objet1 ?objet2) ?q <- (possede ?objet1) (proximite ?objet2) => (printout t "Je dépose " ?objet1 " sur " ?objet2 crlf) (assert (sur ?objet1 ?objet2)) (retract ?p ?q)) (defrule action-aller-vers-1 ?p <- (but aller-vers ?objet) (not (proximite ?)) => (printout t "Je vais vers " ?objet crlf) (assert (proximite ?objet)) (retract ?p)) (defrule action-aller-vers-2 ?p <- (but aller-vers ?objet) ?q <- (proximite ?) => (printout t "Je vais vers " ?objet crlf) (assert (proximite ?objet)) (retract ?p ?q))

35 35 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.2 (tests) Chargement et exécution du code 1.2 : –Peut-on encore améliorer le programme ? cubes3.clp

36 36 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.3 (analyse) Encore quelques petits problèmes : –On suppose que le robot doit systématiquement sapproprier les objets : le robot pourrait déjà posséder lobjet A ! –Il faut vérifier que le robot ne possède pas déjà lobjet à déposer dans la décomposition de laction déposer –On suppose que le robot doit systématiquement se rapprocher des objets : le robot pourrait déjà être à proximité de lobjet B ! –Il faut vérifier que le robot nest pas déjà à proximité de lobjet à déposer dans la décomposition de laction déposer –Comme il faut traiter ces deux cas indépendamment lun de lautre, il faut deux règles pour décomposer laction déposer Plus généralement, il faut sassurer de ne pas recréer des situations qui existent déjà…

37 37 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.3 (codage) (defrule decompose-deposer-1 (but deposer ?objet1 ?objet2) (not (possede ?objet1)) => (assert (but possede ?objet1))) (defrule decompose-deposer-2 (but deposer ?objet1 ?objet2) (not (proximite ?objet2)) => (assert (but proximite ?objet2))) (defrule decompose-prendre (but prendre ?objet) (not (proximite ?objet)) => (assert (but proximite ?objet))) Décomposition du but « déposer-sur »

38 38 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.3 (tests) Lordre des règles est-il important ? cubes4.clp

39 39 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.3 (tests) Examinons la trace des inférences : ==> f-1 (but deposer cube-A cube-B) CLIPS> (run) FIRE 1 decompose-deposer-2: f-1, ==> f-2 (but proximite cube-B) FIRE 2 decompose-proximite: f-2 ==> f-3 (but aller-vers cube-B) <== f-2 (but proximite cube-B) FIRE 3 action-aller-vers-1: f-3, Je vais vers cube-B ==> f-4 (proximite cube-B) <== f-3 (but aller-vers cube-B) FIRE 4 decompose-deposer-1: f-1, ==> f-5 (but possede cube-A) FIRE 5 decompose-possede: f-5 ==> f-6 (but prendre cube-A) <== f-5 (but possede cube-A) FIRE 6 decompose-prendre: f-6, ==> f-7 (but proximite cube-A) FIRE 7 decompose-proximite: f-7 ==> f-8 (but aller-vers cube-A) <== f-7 (but proximite cube-A) FIRE 8 action-aller-vers-2: f-8,f-4 Je vais vers cube-A ==> f-9 (proximite cube-A) <== f-8 (but aller-vers cube-A) <== f-4 (proximite cube-B) FIRE 9 decompose-deposer-2: f-1, ==> f-10 (but proximite cube-B) FIRE 10 decompose-proximite: f-10 ==> f-11 (but aller-vers cube-B) <== f-10 (but proximite cube-B) FIRE 11 action-aller-vers-2: f-11,f-9 Je vais vers cube-B Le robot aurait dû déclencherla règle « action-prendre » Le robot aurait dû déclencherla règle « decompose-deposer-1 »

40 40 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.4 (analyse) Problèmes : –Cycle n°1 : le robot commence par rechercher la proximité du cube B avant de sassurer quil possède lobjet A –A priorité égale, les règles sont prise en compte du haut vers le bas –Cycle n°9 : le robot se préoccupe du but déposer alors quil devrait déclencher la règle action-prendre sur le cube A –La règle est déclenchable mais se trouve en seconde position dans lagenda Commençons par donner une priorité supérieure aux règles daction devant les règles de décomposition (defrule (declare (salience ))...

41 41 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v1.4 (tests) Chargement et exécution du code 1.4 : –Cela ne boucle plus mais il faut quand-même inverser les deux règles decompose-deposer-1 et decompose-deposer-2 cubes5a.clp cubes5b.clp

42 42 © Jérôme Lehuen - Université du Maine - 03/10/01 Quelques commandes de base Commande (clear) : –Vide les bases de connaissances (faits et règles) et lagenda Commande (load ) : –Charge un fichier de constructeurs (deffacts, defrule, etc.) Commande (reset) : –Vide la base de faits, crée un fait (initial-fact), crée les faits déclarés avec le constructeur deffacts et initialise lagenda Commande (run) : –Lance le moteur dinférences jusquà ce que lagenda soit vide Commande (facts) : –Affiche une représentation de la base de faits (sortie standard) Commande (agenda) : –Affiche une représentation de lagenda (sortie standard)

43 43 © Jérôme Lehuen - Université du Maine - 03/10/01 La ligne de commande CLIPS> (load "cubes5b.clp") Defining deffacts: init Defining defrule: action-deposer +j+j+j Defining defrule: action-prendre +j+j... TRUE CLIPS> (facts) CLIPS> (agenda) CLIPS> (reset) CLIPS> (facts) f-0 (initial-fact) f-1 (but deposer cube-A cube-B) For a total of 2 facts. CLIPS> (agenda) 0 decompose-deposer-1: f-1, 0 decompose-deposer-2: f-1, For a total of 2 activations. CLIPS> (run) Je vais vers cube-A Je prends cube-A Je vais vers cube-B Je dépose cube-A sur cube-B CLIPS> (facts) f-0 (initial-fact) f-10 (proximite cube-B) f-11 (sur cube-A cube-B) For a total of 3 facts. CLIPS> (agenda) CLIPS> (clear) CLIPS> (reset) CLIPS> (facts) CLIPS> (agenda) CLIPS> (run) CLIPS> (exit)

44 44 © Jérôme Lehuen - Université du Maine - 03/10/01 Commandes de débuggage Utilisées pour obtenir une trace des inférences : –(watch ) permet dajouter une information à tracer –(unwatch ) permet denlever une information tracée –(dribble-on ) envoie la trace vers un fichier texte –(dribble-off) ferme le fichier de trace CLIPS> (reset) CLIPS> (watch rules) CLIPS> (watch facts) CLIPS> (watch activations) CLIPS> (run) FIRE 1 decompose-deposer-1: f-1, ==> f-2 (but possede cube-A) ==> Activation 0 decompose-possede: f-2 FIRE 2 decompose-possede: f-2 ==> f-3 (but prendre cube-A) ==> Activation 0 decompose-prendre: f-3, <== f-2 (but possede cube-A)

45 45 © Jérôme Lehuen - Université du Maine - 03/10/01 Remarque sur le « not » Pourquoi la règle suivante nest-elle pas déclenchée ? –Une condition de type (not(B)) est traitée comme : –(A) (not(B)) où (A) est la condition précédente –(initial-fact) (not(B)) –On aurait aussi pu inverser les deux conditions CLIPS> (clear) CLIPS> (defrule exemple (not (toto)) (titi) => (printout t "coucou" crlf)) CLIPS> (assert (titi)) CLIPS> (run) CLIPS> (defrule exemple (initial-fact) (not (toto)) (titi) => (printout t "coucou" crlf))

46 46 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

47 47 © Jérôme Lehuen - Université du Maine - 03/10/01 Limites des faits ordonnés Les faits ordonnés (listes) : –Avantage : peuvent être utilisés sans déclaration préalable –Inconvénient : aucun contrôle sur le type des données –Inconvénient : peu explicite (source derreurs potentielles) –Attention : la position dune donnée peut avoir de limportance ! (employe "Dupond" "Jacques" 27 CDD) (employe "Jacques" "Dupond" CDD 27) On voudrais pouvoir typer davantage les données On vaudrais pouvoir manipuler des données sans se soucier dune position dans une liste Différents !

48 48 © Jérôme Lehuen - Université du Maine - 03/10/01 Les faits structurés Fait structuré ou template : –Structure de type enregistrement qui permet de spécifier et daccéder à des attributs ( slots ) appartenant à des faits –Les templates doivent être déclarés avant dêtre utilisés ! –Lordre des attributs na pas dimportance –les attributs peuvent être monovalués ou multivalués Un attribut multivalué se manipule comme un fait ordonné (liste) –On peut spécifier un domaine pour chaque attribut : Type, intervalle, cardinal, valeur par défaut, etc. Avantages : –Beaucoup plus explicites que les faits ordonnés –Contrôle possible du type des données

49 49 © Jérôme Lehuen - Université du Maine - 03/10/01 Les faits structurés Exemple n°1 : (deftemplate employe "Les employés de ma petite entreprise" (slot nom (type STRING)) (slot prenom (type STRING)) (slot age (type INTEGER)) (slot type-contrat (allowed-values CDD CDI) (default CDD))) CLIPS> (assert (employe (prenom "Jacques") (nom "Dupond") (age 27))))

50 50 © Jérôme Lehuen - Université du Maine - 03/10/01 Les faits structurés Exemple n°2 : (deftemplate bidule "Les bidules compliqués" (slot nom (type SYMBOL) (default ?NONE)) (slot id (default-dynamic (gensym))) (slot loc (type SYMBOL) (default ?DERIVE)) (slot poids (allowed-values leger lourd) (default leger)) (multislot pointeurs (type FACT-ADDRESS) (default ?DERIVE))) CLIPS> (assert (bidule)) [TMPLTRHS1] Slot nom requires a value because of its (default ?NONE) attrib CLIPS> (assert (bidule (nom cube))) CLIPS> (assert (bidule (nom bloc) (poids lourd)) CLIPS> (facts) f-0 (bidule (nom cube) (id gen1) (loc nil) (poids leger) (pointeurs)) f-1 (bidule (nom bloc) (id gen2) (loc nil) (poids lourd) (pointeurs)) For a total of 2 facts.

51 51 © Jérôme Lehuen - Université du Maine - 03/10/01 Syntaxe BNF de deftemplate (deftemplate [ ] *) ::= | ::= (slot *) ::= (multislot *) ::= | ::= (default ?DERIVE | ?NONE | *) | (default-dynamic *) ::= (type +) | (allowed-values +) | (allowed-symbols +) | (range ) | (cardinality )

52 52 © Jérôme Lehuen - Université du Maine - 03/10/01 Typologie des données Seules valeurs possibles de lors de la spécification du type dun attribut : –INTEGER : nombres entiers relatifs –FLOAT : nombres à virgule flottante (notation habituelle) –STRING : chaînes de caractères (notation habituelle) –SYMBOL : symboles (séquences insécables de caractères) –FACT-ADDRESS : pointeurs pour accéder directement aux faits –INSTANCE-NAME : noms des objets de la couche COOL –INSTANCE-ADDRESS : pointeurs pour accéder aux objets –EXTERNAL-ADDRESS : pointeurs de données externes

53 53 © Jérôme Lehuen - Université du Maine - 03/10/01 Le monde des cubes II Ils sont de retour, et bien décidés à se venger ! –On voudrait avoir un groupe de robots de même type –On voudrait affiner la description des robots, des objets et de lenvironnement (aller vers une topologie des lieux) : –Lenvironnement est une configuration de salles (hangar, entrepôt, etc.) –Un objet doit être soit dans une salle, soit transporté par un robot –A terme, ce serait bien que les robots puissent communiquer et coopérer (agir sans compétition) à une tâche collective –Ce problème nest pas traité dans ce cours mais vous êtes libres dy penser !

54 54 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v2.0 (analyse) Adaptons le « modèle du monde » : –Un objet possède un « id » et une localisation (salle ou robot) –Un robot possède un « id » et une localisation (salle) –Pour simplifier, on va considérer que la notion de « proximité » correspond à la notion de « même localisation » –Un robot peut déplacer plusieurs objets en même temps –Le robot possède un objet lorsque la localisation de lobjet est le robot (deftemplate objet (slot id (type SYMBOL) (default ?NONE)) (slot localisation (type SYMBOL) (default entrepot))) (deftemplate robot (slot id (type SYMBOL) (default ?NONE)) (slot localisation (type SYMBOL) (default hangar)))

55 55 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v2.0 (codage) Exemple de règle daction (action déposer) : Modification de la valeur dun attribut (defrule action-deposer (declare (salience 5)) ?but <- (but ?id-robot deposer ?id-objet1 ?id-objet2) ;; Le robot possède lobjet1 ?objet1 <- (objet (id ?id-objet1) (localisation ?id-robot)) ;; Le robot et lobjet2 sont dans le même lieu (robot (id ?id-robot) (localisation ?lieu)) (objet (id ?id-objet2) (localisation ?lieu)) => (printout t ?id-robot " dépose " ?id-objet1 " sur " ?id-objet2 crlf) ;; Lobjet1 change de localisation (modify ?objet1 (localisation ?lieu)) ;; Le but est atteint (assert (sur ?id-objet1 ?id-objet2)) (retract ?but))

56 56 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v2.0 (codage) Modification dun fait structuré (commande modify) : Exemple de règle de décomposition (but prendre) : Contrainte « différent de » (modify ( )+ ) (defrule decompose-prendre (but ?id-robot prendre ?id-objet) ;; Le robot nest pas à proximité de lobjet (objet (id ?id-objet) (localisation ?lieu)) (robot (id ?id-robot) (localisation ~?lieu)) => ;; Le robot doit être à proximité de lobjet (assert (but ?id-robot proximite ?id-objet)))

57 57 © Jérôme Lehuen - Université du Maine - 03/10/01 LMDC v2.0 (tests) Chargement et exécution du code 2.0 : cubes6.clp

58 58 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

59 59 © Jérôme Lehuen - Université du Maine - 03/10/01 Manipulation des listes En CLIPS, la représentation des connaissances repose essentiellement sur les listes : –Les faits ordonnés sont des listes –Les valeurs des attributs multivalués sont des listes –Attention : le premier élément dune liste a un statut particulier Nouveau problème : –On veux fabriquer une liste de valeurs à partir de faits isolés –Lordre des valeurs na pas dimportance pour linstant –Si la liste « réceptrice » nexiste pas dans la BDF, il faudra la créer (data 12) (data 3) (data 7) (data 10) (liste )

60 60 © Jérôme Lehuen - Université du Maine - 03/10/01 Manipulation des listes Création dune nouvelle liste : –Sil y a un fait « data » et sil ny a pas de fait « liste » –Alors créer un fait liste avec la valeur du fait « data » Ajout dune valeur dans une liste existante : –Sil y a un fait « data » et un fait « liste » –Alors ajouter la valeur du fait « data » à la fin du fait « liste » (defrule ajoute-valeur ?donnee <- (data ?valeur) ?liste <- (liste $?contenu) => (retract ?donnee ?liste) (assert (liste ?contenu ?valeur))) (defrule cree-liste ?donnee <- (data ?valeur) (not (liste $?)) => (retract ?donnee) (assert (liste ?valeur)))

61 61 © Jérôme Lehuen - Université du Maine - 03/10/01 Manipulation des listes Recherche dune valeur dans une liste : –La valeur à rechercher est indiquée dans un fait « chercher » Suppression dune valeur dans une liste : –La valeur à rechercher est indiquée dans un fait « supprimer » (defrule recherche-valeur ?but <- (chercher ?valeur) (liste $? ?valeur $?) => (retract ?but) (printout t "je trouve " ?valeur crlf)) (defrule supprime-valeur ?but <- (supprimer ?valeur) ?liste <- (liste $?avant ?valeur $?apres) => (retract ?but ?liste) (assert (liste ?avant ?apres)))

62 62 © Jérôme Lehuen - Université du Maine - 03/10/01 Manipulation des listes On veux connaître la position dune valeur : –Adaptons la règle « recherche-valeur » : (defrule recherche-valeur ?but <- (chercher ?valeur) (liste $? ?valeur $?) => (retract ?but) (printout t "je trouve " ?valeur crlf)) (defrule recherche-valeur-pos ?but <- (chercher ?valeur) (liste $?avant ?valeur $?) => (retract ?but) (printout t "position : " (+ (length$ ?avant) 1) crlf)) Fonction sur les listes

63 63 © Jérôme Lehuen - Université du Maine - 03/10/01 Fonctions sur les listes (defglobal ?*liste* = (create$ a b c d)) ?*liste* (a b c d) (create$ a b c d) (a b c d) (length$ ?*liste*) 4 (first$ ?*liste*) (a) (rest$ ?*liste*) (b c d) (nth$ 2 ?*liste*) b (member$ b ?*liste*) 2 (insert$ ?*liste* 2 #) (a # b c d) (insert$ ?*liste* 2 ?*liste*) (a a b c d b c d) (delete$ ?*liste* 2 3) (a d) (subseq$ ?*liste* 2 3) (b c) (replace$ ?*liste* 2 3 #) (a # d) (subsetp (create$ b c) ?*liste*) TRUE (implode$ ?*liste*) "a b c d" (explode$ "a b c d") (a b c d) Déclaration dune variable globale

64 64 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

65 65 © Jérôme Lehuen - Université du Maine - 03/10/01 Autres fonctions Fonctions sur les chaînes : –(str-cat *), (sub-string ), –(str-index ), (str-compare ), –(str-length ), (upcase ), (lowcase )... Fonctions arithmétiques : –(+ +), (- +), (* +), –(/ +), (div ), (mod ), –(** ), (exp ), (log ), –(max +), (min +), (abs ), (sqrt )... Fonctions trigonométriques (25) : –(sin ), (cos ), (tan ), (sinh )... Transtypage et conversion : –(float ), (integer ), –(deg-rad ), (rad-deg )...

66 66 © Jérôme Lehuen - Université du Maine - 03/10/01 Prédicats Fonctions qui retournent TRUE ou FALSE –Utilisables avec la condition « test » dans les LHS –Utilisables avec les commandes « if » et « while » dans les RHS Prédicats de type : –(numberp ), (integerp ), (floatp ), –(stringp ), (symbolp ), (multifieldp )... Prédicats de comparaison : –(eq +), (neq +), (= +), –(> +), (>= +)... Prédicats booléens : –(and +), (or +), (not ) Autres prédicats : –(oddp ), (evenp ), (subsetp )...

67 67 © Jérôme Lehuen - Université du Maine - 03/10/01 Fonctions "procédurales" Liaison variable-expression : –(bind ) Si … alors … sinon : –(if then * [else *]) Boucle tant que : –(while [do] *) Boucle pour : –(loop-for-count [do] *) – ::= | ( [ ]) Boucle pour chaque : –(progn$ ( ) *) Sélectionner selon : –(switch (case then *)+)

68 68 © Jérôme Lehuen - Université du Maine - 03/10/01 Entrées et sorties Opérations sur les fichiers : –(open [ ]) "r" (lecture seule) "w" (écriture seule) "r+" (lecture et écriture) "a" (ajout) –(close [ ]) –(rename ) –(remove ) –(dribble-on ) (dribble-off) Lecture et écriture dans un flux dentrée/sortie : –(read [ ]) –(readline [ ]) –(printout *) –(format *)

69 69 © Jérôme Lehuen - Université du Maine - 03/10/01 Définir des nouvelles fonctions Syntaxe qui ne déroute pas les Lispiens : –Comme en Lisp, la récursivité est la meilleure méthode pour manipuler et transformer les listes –Par convention, les fonctions dont le nom se termine par $ prennent une liste en argument –Le constructeur deffunction permet décrire des nouvelles commandes CLIPS utilisables dans les RHS des règles (defun coupe (liste index) (if (eq index 0) liste (coupe (cdr liste) (- index 1)))) LISP> (coupe (list ) 2) (3 4) (deffunction coupe$ (?liste ?index) (if (eq ?index 0) then ?liste else (coupe$ (rest$ ?liste) (- ?index 1)))) CLIPS> (coupe$ (create$ ) 2) (3 4) Version LISPVersion CLIPS

70 70 © Jérôme Lehuen - Université du Maine - 03/10/01 Synthèse des constructeurs Permettent de déclarer des connaissances (un fichier CLP est constitué de constructeurs) : –deftemplate : déclaration dun template –deffacts : déclaration dun ensemble de faits initiaux –defrule : déclaration dune règle –defglobal : déclaration dune variable globale –deffunction : déclaration dune fonction ou dune commande –defmodule : déclaration dun module Concernent la couche COOL : –defclass : déclaration dune classe par héritage –defmessage-handler : déclaration dune méthode dinstance –definstance : déclaration dune instance –defmethod : déclaration dune fonction générique

71 71 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

72 72 © Jérôme Lehuen - Université du Maine - 03/10/01 Écriture des conditions (1) Condition de type filtre : –Les symboles ? et $? sont les jokers monovalué et multivalué –Les variables multivaluées sont forcément liées avec des listes –Possibilité décrire des contraintes complexes Condition booléenne : –La syntaxe des appels fonctionnels est de type Lisp : ::= (... ) | ( ( )*) ::= | ? | $? | ? | $? (defrule operator-condition (data ?oper ?x) (value ?oper ?y) (test (> (abs (- ?y ?x)) 3)) => (assert (valid ?oper TRUE))) ::= (test )

73 73 © Jérôme Lehuen - Université du Maine - 03/10/01 Écriture des conditions (2) Opérateurs booléens : –Attention à lutilisation du NOT ! –Le AND nest utile quen combinaison avec le OR : ::= (not ) ::= (or +) ::= (and +) (defrule high-flow-rate (temp high) (valve open) (not (error-status confirmed)) => (assert (warning "High Temp - Recommend closing of valve"))) (defrule system-flow (error-status confirmed) (or (and (temp high) (valve closed)) (and (temp low) (valve open))) => (assert (alert (level 3) (text "Flow problem"))))

74 74 © Jérôme Lehuen - Université du Maine - 03/10/01 Écriture des conditions (3) Condition existentielle : –Permet de tester si un ensemble de filtres est satisfait par au moins un ensemble de faits (ne génère aucune combinatoire) : (deffacts faits-initiaux (nous sommes en danger) (super-hero "Super Man" occupe) (super-hero "Spider Man" disponible) (super-hero "Wonder Woman" disponible) (super-hero "Flash Gordon" occupe)) (defrule dont-worry ?p <- (nous sommes en danger) (exists (super-hero ? disponible)) => (retract ?p)) ::= (exists +)

75 75 © Jérôme Lehuen - Université du Maine - 03/10/01 Écriture des conditions (4) Condition universelle : –Permet de tester si un ensemble de filtres est satisfait pour chaque occurrence dun autre filtre : ::= (forall +) (defrule all-students-passed ?but <- (bilan ?classe) (forall (eleve ?nom ?classe) (lecture-OK ?nom) (ecriture-OK ?nom) (math-OK ?nom)) => (retract ?but) (assert (bilan ?classe all-students-passed)))

76 76 © Jérôme Lehuen - Université du Maine - 03/10/01 Contraintes complexes Pratique et concis mais source derreurs ! –Contraintes avec des négations : (personne (age ~30)) (personne (age ?x&~20)) (personne (age ?x&~20&~30)) –Contraintes avec des appels fonctionnels : (personne (age ?x&~:(oddp ?x))) (personne (age ?x&:(> ?x 30)&:(< ?x 40))) –Que vérifie la règle suivante ? (defrule regle-bidon (personne (nom ?x) (age ?y)) (personne (nom ~?x) (age ?w&?y|=(* 2 ?y))) => (assert (vraiment bidon la regle)))

77 77 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

78 78 © Jérôme Lehuen - Université du Maine - 03/10/01 Le moteur de CLIPS Compilation de la base de règles : –Les règles sont compilées « en dur » sous la forme dun réseau –Le système ne regarde que ce qui change pour les règles concernées quand de nouveaux faits sont ajoutés ou modifiés –La base de faits est intimement liée à la base de règles –Les faits sont triés et propagés très rapidement Réseau RETE et algorithme de propagation : –Implémentés pour la première fois dans les années 90 (OPS 5) –Les règles sont compilées sous la forme de deux réseaux : –Arbre de discrimination : filtrer et propager les nouveaux faits Chaque feuille contient une prémisse et chaque nœud un test –Réseau de jointures : vérifier les correspondances entre variables Chaque nœud regroupe 2 à 2 les prémisses dune même règle

79 79 © Jérôme Lehuen - Université du Maine - 03/10/01 Exemple de compilation Soit les deux règles suivantes : (defrule make-goal-near (goal monkey on ?x) (near ?x ?y) => (assert (goal monkey near ?y))) (defrule make-goal-emptyhanded (goal monkey on ?x) (near ?x ?y) (monkey near ?y) => (assert (goal emptyhanded monkey)))

80 80 © Jérôme Lehuen - Université du Maine - 03/10/01 Arbre de discrimination taille = 3 monkey near taille = 4 goal monkey on (monkey near ?y) (goal monkey on ?x) nœud de distribution (near ?x ?y) Propage et filtre chaque nouveau fait : –Le nœud de distribution duplique et envoie des tokens +fait –Les tokens sont propagés (ou non) dans les branches de larbre :

81 81 © Jérôme Lehuen - Université du Maine - 03/10/01 Réseau de jointures Vérifie les correspondances entre les variables : –Les nœuds regroupent 2 à 2 les prémisses dune même règle –Les substitutions sont propagées (ou non) aux nœuds suivants : (monkey near ?y)(goal monkey on ?x)(near ?x ?y)(goal monkey on ?x)(near ?x ?y) ?x ?y ?x (assert (goal emptyhanded monkey))) (assert (goal monkey near ?y)))

82 82 © Jérôme Lehuen - Université du Maine - 03/10/01 Première optimisation Factoriser les feuilles de larbre de discrimination : (monkey near ?y)(goal monkey on ?x)(near ?x ?y) ?x ?y (assert (goal emptyhanded monkey))) ?x (assert (goal monkey near ?y)))

83 83 © Jérôme Lehuen - Université du Maine - 03/10/01 Seconde optimisation Factoriser les nœuds du réseau de jointures : (monkey near ?y)(goal monkey on ?x)(near ?x ?y) ?x ?y (assert (goal emptyhanded monkey))) (assert (goal monkey near ?y)))

84 84 © Jérôme Lehuen - Université du Maine - 03/10/01 L = 3 monkey near L = 4 goal monkey on (monkey near ?y) (goal monkey on ?x) nœud de distribution (assert (goal monkey near ?y)) (assert (goal emptyhanded monkey)) Réseau optimisé Arbre de discrimination (near ?x ?y) ?x?y Réseau de jointures

85 85 © Jérôme Lehuen - Université du Maine - 03/10/01 Efficacité de RETE (defrule mauvaise-regle (item ?x) (item ?y) (item ?z) (item ?w) (liste ?x ?y ?z ?w) => (defrule bonne-regle (liste ?x ?y ?z ?w) (item ?x) (item ?y) (item ?z) (item ?w) => Cette règle doit générer toutes les permutations possibles des faits « item » avant de trouver une permutation qui corresponde au fait « liste » Sil y a n faits, il y aura n ! / (n-p) ! configurations à mémoriser (avec 10 faits, cela fait 10 x 9 x 8 x 7 = 5040 configurations différentes). Pour une exécution efficace, il est essentiel de placer les conditions les plus contraignantes (celles qui ont le moins de chance dêtre vérifiées) avant les autres. Lefficacité dun réseau RETE ne dépend pas tellement du nombre de règles et de faits, mais du nombre de correspondances partielles générées et stockées :

86 86 © Jérôme Lehuen - Université du Maine - 03/10/01 Stratégies de résolution Stratégies de résolution de conflits : –Stratégies Depth et Breadth : –Insertion au début de lagenda des tâches (profondeur dabord) –Insertion à la fin de lagenda des tâches (largeur dabord) –Stratégie Random : –Les règles de même intérêt sont insérées dans lagenda de façon aléatoire –Stratégies Simplicity et Complexity : –Insertion en fonction de la spécificité croissante (simplicité dabord) –Insertion en fonction de la spécificité décroissante (complexité dabord) Exemple : la spécificité de la règle ci-dessous est de 5 : –Stratégies Lex et Mea : –Voir pages suivantes (defrule exemple (item ?x ?y ?x) (test (and (numberp ?x) (> ?x (+ 10 ?y)) (< ?x 20)))

87 87 © Jérôme Lehuen - Université du Maine - 03/10/01 Stratégies Lex et Mea Stratégie Lex : –Favorise les règles qui utilisent les déductions les plus récentes –Favorise les règles qui utilisent le plus de conditions –Les négations sont moins prioritaires que les autres conditions Stratégie Mea : –La première prémisse de chaque règle est prioritaire –La stratégie Lex est utilisée pour résoudre les conflits restants Exemple : (deffacts faits-initiaux (f-1) (f-2) (f-3) (f-4)) (defrule R1 (f-1) (f-2) (f-3) =>... ) (defrule R2 (f-3) (f-1) =>... ) (defrule R3 (f-2) (f-1) =>... ) (defrule R4 (f-1) (f-2) (not (f-5)) =>... ) (defrule R5 (f-1) (f-2) (f-3) (not (f-5)) =>... ) (defrule R6 (f-1) (f-4) =>... )

88 88 © Jérôme Lehuen - Université du Maine - 03/10/01 Stratégies Lex et Mea Agenda trié en fonction de la stratégie Lex : Agenda trié en fonction de la stratégie Mea : nn nn R6R5R1R2R4R3R6R5R1R2R4R nn nn R2R3R6R5R1R4R2R3R6R5R1R4 Première prémisse Lex

89 89 © Jérôme Lehuen - Université du Maine - 03/10/01 Plan du cours Présentation de CLIPS (historique, caractéristiques) Survol de CLIPS (faits, règles, filtrage, agenda) Le monde des cubes (trace, débuggage, négation) Justification et utilisation des structures (templates) Manipulation des listes et fonctions sur les listes Aspects fonctionnels (fonctions, prédicats, E/S) Synthèse sur les conditions et contraintes complexes Le moteur CLIPS (réseau RETE, résolution de conflits) Aperçu de la couche COOL (classes et méthodes)

90 90 © Jérôme Lehuen - Université du Maine - 03/10/01 La couche COOL CLIPS Object Oriented Language : –Abstraction + héritage + encapsulation + polymorphisme –Sortes de templates hiérarchisés avec héritage multiple –La classe générique est OBJECT mais on utilise plutôt USER –Une classe est réactive lorsque ses instances peuvent être filtrées (defclass (is-a *) (role abstract|concrete) [(pattern-match reactive)] (slot|multislot [(type )]... )*) CLIPS> (defclass DUCK (is-a USER) (role concrete)) CLIPS> (make-instance of DUCK) [gen1] CLIPS> (make-instance Gaetan of DUCK) [Gaetan]

91 91 © Jérôme Lehuen - Université du Maine - 03/10/01 Hiérarchie des classes OBJECT PRIMITIVEUSER INITIAL-OBJECTNUMBERINSTANCEADDRESSEMULTIFIELDLEXEME FLOATINTEGER INSTANCE-NAME INSTANCE-ADDRESS FACT-ADDRESS EXTERNAL-ADDRESS STRINGSYMBOL

92 92 © Jérôme Lehuen - Université du Maine - 03/10/01 La classe des canards (defclass DUCK (is-a USER) (role concrete) (slot son (create-accessor read-write)) (slot age (create-accessor read-write) (default 0))) (defmessage-handler DUCK parler (?phrase) (printout t ?phrase crlf)) (defmessage-handler DUCK parler before (?phrase) (printout t ?self:son " ")) (definstances objets-initiaux (Donald of DUCK)) CLIPS> (reset) CLIPS> (send [Donald] put-son coin-coin) CLIPS> (send [Donald] print) CLIPS> (make-instance Gaetan of DUCK (son coui-coui) (age 2)) CLIPS> (send [Gaetan] get-age) CLIPS> (instances) CLIPS> (send [Donald] parler "Hello World") À tester

93 93 © Jérôme Lehuen - Université du Maine - 03/10/01 Filtrage des objets (defclass DUCK (is-a USER) (role concrete) (pattern-match reactive) (slot son (create-accessor read-write)) (slot age (create-accessor read-write) (default 0))) (definstances OBJETS-INITIAUX (Donald of DUCK (son coin-coin) (age 2)) (Gaetan of DUCK (son coui-coui) (age 4)) (Gedeon of DUCK (son piou-piou) (age 5)) (Daisy of DUCK (son pouet-pouet))) (defmessage-handler DUCK crier () (printout t ?self ?self:son crlf))) (defrule klaxon ?canard <- (object (is-a DUCK) (age ~0)) => (send ?canard crier))

94 94 © Jérôme Lehuen - Université du Maine - 03/10/01 Thats all Folks !


Télécharger ppt "1 © Jérôme Lehuen - Université du Maine - 03/10/01 Représentation des connaissances –Représentation des faits –Représentation des règles –Programmation."

Présentations similaires


Annonces Google