94
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 d’infé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 n’est pas un manuel de référence mais un support de cours La documentation CLIPS est téléchargeable sur le site web suivant : http://www.ghg.net/clips/CLIPS.html

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

Embed Size (px)

Citation preview

Page 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

• Représentation des connaissances– Représentation des faits– Représentation des règles– Programmation fonctionnelle

• Moteur d’infé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 n’est pas un manuel de référence mais un support de coursLa documentation CLIPS est téléchargeable sur le site web suivant :http://www.ghg.net/clips/CLIPS.html

Page 2: 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Rappels

• Problématique :– Pas toujours facile (ni même possible) d’exprimer 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 n’existe 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

Page 3: 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Connaissances d’un 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 d’infé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 d’infé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

Page 4: 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Règles

Faits

Architecture d’un 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 d’inférences : Applique les règles aux faits

ajouts / modifications / suppressions

règles d’inférence

faits initiaux

règles du domaine

autres actions

Page 5: 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Exemple de la déduction

Modus Ponens Modus 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 :

Page 6: 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 7: 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 d’ordre 1 fonctionnant en chaînage avant (Modus Ponens)– Implémentation en langage C de l’algorithme 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

Page 8: 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 d’infé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 s’inspire 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

Page 9: 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

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Interface graphique

Page 10: 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

10©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 11: 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

11©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Gestion de la BDF

• Ajouter un fait dans la BDF :

CLIPS> (assert (homme Socrate))<fact-0>

CLIPS> (assert (mortel Socrate))

<fact-1>

• Retirer un fait de la BDF :

CLIPS> (retract 0)

Page 12: 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

12©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)))

Page 13: 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

13©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)))

Page 14: 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

14©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Syntaxe des faits

• Fait ordonné ou pattern :– Liste constituée d’un symbole (la relation) suivi d’une

séquence (éventuellement vide) de données séparées par des espaces

– Une donnée doit être de l’un des huit types CLIPS (voir typologie)– Un symbole est une séquence de n’importe quels caractères ASCII

à l’exception des caractères suivants : ( ) < > & $ | ; ? ~• Les faits CLIPS n’acceptent 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)

Page 15: 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

15©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Syntaxe des règles

• Constructeur de règles :– Constitué d’une séquence de conditions suivie d’une

séquence d’actions à 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 <identificateur>

[commentaire] ; Chaîne de caractères<filtre>* ; LHS (Left-Hand Side)=><action>*) ; RHS (Right-Hand Side)

Page 16: 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

16©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 s’apparient 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) =>)

Page 17: 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

17©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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°4pompe.clp

Page 18: 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

18©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Agenda de tâches

- Initialiser l’agenda- Tant qu’il reste des tâches dans l’agenda :

- Effectuer la première tâche- Mettre à jour l’agenda :

- Supprimer les tâches obsolètes- Insérer les nouvelles tâches

• Principe :– Maintenir une file d’attente (ordonnée) d’activations

Règles

Faits Rule : R034Priority : 10Substs : { }

Page 19: 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

19©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 d’extinction n’est plus nécessaire"(logical (refrigerator door open))=>(assert (refrigerator light on)))

Page 20: 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

20©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Dépendance logique

• Attention c’est un peu plus compliqué qu’il n’y 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

<Fact-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)

Page 21: 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

21©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 22: 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

22©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Le monde des cubes

• On veut écrire la partie « I.A. » d’un robot mobile :– Le robot doit effectuer des actions en fonction de

connaissances sur son environnement et d’un but qui lui est donné

– Ses actions doivent être le résultat d’un 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 à l’aide de faits stockés dans la base de faits

– Raisonnement du robot :– Un but peut donner lieu à une série de sous-buts et d’actions

(planification)– Implémenté à l’aide de règles portant sur les faits

Page 23: 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

23©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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

l’objet A et être à proximité de l’objet 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é d’un objet, il faut aller vers cet

objetDéposer A sur B

Posséder A

Prendre A

Aller vers B

Être à proximité de A Aller vers A

1 2

but

but but

but but

but

but

Être à proximité de B

Page 24: 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

24©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v1.0 (analyse)

• Les actions du robot :

– Action : déposer un objet A sur un objet B– Conséquence : l’objet A est sur l’objet B– Condition : posséder l’objet A– Condition : être à proximité de l’objet B

– Action : prendre un objet– Conséquence : possession de l’objet– Condition : être à proximité de l’objet

– Action : aller vers un objet– Conséquence : être à proximité de l’objet

Page 25: 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

25©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 l’objet A– Sous-but : être à proximité de l’objet B

– But : posséder un objet– Sous-but : prendre l’objet

– But : prendre un objet– Sous-but : être à proximité de l’objet

– But : être à proximité d’un objet– Sous-but : aller vers l’objet

Page 26: 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

26©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)))

Page 27: 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

27©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)))

Page 28: 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

28©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v1.0 (tests)

• Chargement et exécution du code 1.0 :

– Que penser de la base de faits après l’exécution ?

cubes1.clp

Page 29: 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

29©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 d’une règle ?– On mémorise son fact-address dans une variable– On fait un retract en lui passant l’adresse du fait :

(defrule <identificateur>

...<variable> <- <filtre> ; Mémorisation...=>(retract <variable>) ; Suppression

... )

Page 30: 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

30©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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))

Page 31: 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

31©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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))

Page 32: 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

32©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v1.1 (tests)

• Chargement et exécution du code 1.1 :

– Que penser de la base de faits après l’exécution ?

cubes2.clp

Page 33: 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

33©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 s’il n’y a pas de fait « proximité » dans le base de faits ?

• Tester l’absence d’un fait dans le LHS d’une règle :– Condition d’absence : (not <filtre>)

Page 34: 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

34©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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))

Page 35: 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

35©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v1.2 (tests)

• Chargement et exécution du code 1.2 :

– Peut-on encore améliorer le programme ?

cubes3.clp

Page 36: 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

36©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v1.3 (analyse)

• Encore quelques petits problèmes :

– On suppose que le robot doit systématiquement s’approprier les objets : le robot pourrait déjà posséder l’objet A !

– Il faut vérifier que le robot ne possède pas déjà l’objet à déposer dans la décomposition de l’action déposer

– On suppose que le robot doit systématiquement se rapprocher des objets : le robot pourrait déjà être à proximité de l’objet B !

– Il faut vérifier que le robot n’est pas déjà à proximité de l’objet à déposer dans la décomposition de l’action déposer

– Comme il faut traiter ces deux cas indépendamment l’un de l’autre, il faut deux règles pour décomposer l’action déposer

• Plus généralement, il faut s’assurer de ne pasrecréer des situations qui existent déjà…

Page 37: 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

37©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 »

Page 38: 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

38©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v1.3 (tests)

• L’ordre des règles est-il important ?

cubes4.clp

Page 39: 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

39©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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-4Je 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-9Je vais vers cube-B

Le ro

bot a

ura

it dû

d

écle

nch

er

la rè

gle

« a

ctio

n-p

ren

dre

 »

Le ro

bot a

ura

it dû

décle

nch

er

la rè

gle

« d

ecom

pose-d

ep

oser-

1 »

Page 40: 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

40©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v1.4 (analyse)

• Problèmes :

– Cycle n°1 : le robot commence par rechercher la proximité du cube B avant de s’assurer qu’il possède l’objet 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 qu’il 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 l’agenda

• Commençons par donner une priorité supérieure aux règles d’action devant les règles de décomposition

(defrule <identificateur>

(declare (salience <entier>))

...

Page 41: 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

41©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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

Page 42: 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

42©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Quelques commandes de base• Commande (clear) :

– Vide les bases de connaissances (faits et règles) et l’agenda

• Commande (load <fichier>) :– 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 l’agenda

• Commande (run) :– Lance le moteur d’inférences jusqu’à ce que l’agenda soit vide

• Commande (facts) :– Affiche une représentation de la base de faits (sortie standard)

• Commande (agenda) :– Affiche une représentation de l’agenda (sortie standard)

Page 43: 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

43©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

La ligne de commande

CLIPS> (load "cubes5b.clp")Defining deffacts: initDefining defrule: action-deposer

+j+j+jDefining defrule: action-prendre +j+j...TRUECLIPS> (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-AJe prends cube-AJe vais vers cube-BJe dépose cube-A sur cube-BCLIPS> (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)

Page 44: 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

44©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Commandes de débuggage• Utilisées pour obtenir une trace des inférences :

– (watch <item>) permet d’ajouter une information à tracer

– (unwatch <item>) permet d’enlever une information tracée

– (dribble-on <file>) 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-2FIRE 2 decompose-possede: f-2==> f-3 (but prendre cube-A)==> Activation 0 decompose-prendre: f-3,<== f-2 (but possede cube-A)

Page 45: 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

45©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Remarque sur le « not »

• Pourquoi la règle suivante n’est-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))

Page 46: 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

46©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 47: 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

47©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 d’erreurs potentielles)– Attention : la position d’une donnée peut avoir de

l’importance !

(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 d’une position dans une liste

Différents !

Page 48: 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

48©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Les faits structurés

• Fait structuré ou template :– Structure de type enregistrement qui permet de

spécifier et d’accéder à des attributs (slots) appartenant à des faits

– Les templates doivent être déclarés avant d’être utilisés !

– L’ordre des attributs n’a pas d’importance– 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

Page 49: 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

49©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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))))<fact-0>

Page 50: 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

50©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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) attribCLIPS> (assert (bidule (nom cube)))<fact-0>CLIPS> (assert (bidule (nom bloc) (poids lourd))<fact-1>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.

Page 51: 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

51©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Syntaxe BNF de deftemplate(deftemplate <deftemplate-name> [<comment>] <slot-definition>*)

<slot-definition> ::= <single-slot-def> | <multislot-def>

<single-slot-def> ::= (slot <slot-name> <template-attrib>*)

<multislot-def> ::= (multislot <slot-name> <template-attrib>*)

<template-attrib> ::= <default-attrib> | <constraint-attrib>

<default-attrib> ::= (default ?DERIVE | ?NONE | <expression>*) |

(default-dynamic <expression>*)

<constraint-attrib> ::= (type <allowed-type>+) |

(allowed-values <value>+) |

(allowed-symbols <symbol>+) |

.........

(range <number> <number>) |

(cardinality <integer> <integer>)

Page 52: 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

52©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Typologie des données

• Seules valeurs possibles de <allowed-type> lors de la spécification du type d’un 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

Page 53: 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

53©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 l’environnement (aller vers une topologie des lieux) :

– L’environnement 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 n’est pas traité dans ce cours mais vous êtes libres d’y penser !

Page 54: 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

54©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 l’objet 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)))

Page 55: 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

55©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v2.0 (codage)

• Exemple de règle d’action (action déposer) :

Modification de lavaleur d’un attribut

(defrule action-deposer

(declare (salience 5))

?but <- (but ?id-robot deposer ?id-objet1 ?id-objet2)

;; Le robot possède l’objet1?objet1 <- (objet (id ?id-objet1) (localisation ?id-robot))

;; Le robot et l’objet2 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)

;; L’objet1 change de localisation(modify ?objet1 (localisation ?lieu))

;; Le but est atteint(assert (sur ?id-objet1 ?id-objet2))(retract ?but))

Page 56: 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

56©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v2.0 (codage)

• Modification d’un fait structuré (commande modify) :

• Exemple de règle de décomposition (but prendre) :

Contrainte« différent de »

(modify <fact-adress> (<attribut> <valeur>)+ )

(defrule decompose-prendre

(but ?id-robot prendre ?id-objet)

;; Le robot n’est pas à proximité de l’objet(objet (id ?id-objet) (localisation ?lieu))(robot (id ?id-robot) (localisation ~?lieu))

=>;; Le robot doit être à proximité de l’objet(assert (but ?id-robot proximite ?id-objet)))

Page 57: 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

57©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

LMDC v2.0 (tests)

• Chargement et exécution du code 2.0 :

cubes6.clp

Page 58: 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

58©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 59: 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

59©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 d’une liste a un statut

particulier

• Nouveau problème :– On veux fabriquer une liste de valeurs à partir de faits

isolés– L’ordre des valeurs n’a pas d’importance pour l’instant– Si la liste « réceptrice » n’existe pas dans la BDF, il faudra la créer(data 12)(data 3)(data 7)(data 10)

(liste 10 12 3 7)

Page 60: 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

60©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Manipulation des listes

• Création d’une nouvelle liste :– S’il y a un fait « data » et s’il n’y a pas de fait « liste »– Alors créer un fait liste avec la valeur du fait « data »

• Ajout d’une valeur dans une liste existante :– S’il 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)))

Page 61: 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

61©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Manipulation des listes

• Recherche d’une valeur dans une liste :– La valeur à rechercher est indiquée dans un fait

« chercher »

• Suppression d’une 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)))

Page 62: 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

62©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Manipulation des listes

• On veux connaître la position d’une 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

Page 63: 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

63©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 d’unevariable globale

Page 64: 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

64©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 65: 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

65©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Autres fonctions

• Fonctions sur les chaînes :– (str-cat <expr>*), (sub-string <int> <int> <expr>),– (str-index <expr> <expr>), (str-compare <expr> <expr>),– (str-length <expr>), (upcase <expr>), (lowcase <expr>)...

• Fonctions arithmétiques :– (+ <expr> <expr>+), (- <expr> <expr>+), (* <expr> <expr>+),– (/ <expr> <expr>+), (div <expr> <expr>), (mod <expr> <expr>),– (** <expr> <expr>), (exp <expr>), (log <expr>),– (max <expr>+), (min <expr>+), (abs <expr>), (sqrt <expr>)...

• Fonctions trigonométriques (25) :– (sin <expr>), (cos <expr>), (tan <expr>), (sinh <expr>)...

• Transtypage et conversion :– (float <expr>), (integer <expr>),– (deg-rad <expr>), (rad-deg <expr>)...

Page 66: 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

66©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 <expr>), (integerp <expr>), (floatp <expr>),– (stringp <expr>), (symbolp <expr>), (multifieldp <expr>)...

• Prédicats de comparaison :– (eq <expr> <expr>+), (neq <expr> <expr>+), (= <expr> <expr>+),– (> <expr> <expr>+), (>= <expr> <expr>+)...

• Prédicats booléens :– (and <expr>+), (or <expr>+), (not <expr>)

• Autres prédicats :– (oddp <expr>), (evenp <expr>), (subsetp <expr> <expr>)...

Page 67: 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

67©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Fonctions "procédurales"

• Liaison variable-expression :– (bind <variable> <expression>)

• Si … alors … sinon :– (if <expression> then <action>* [else <action>*])

• Boucle tant que :– (while <expression> [do] <action>*)

• Boucle pour :– (loop-for-count <range> [do] <action>*)– <range> ::= <end-index> | (<variable> [<start> <end>])

• Boucle pour chaque :– (progn$ (<variable> <expression>) <expression>*)

• Sélectionner selon :– (switch <test> (case <expression> then <action>*)+)

Page 68: 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

68©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Entrées et sorties

• Opérations sur les fichiers :– (open <file-name> <logical-name> [<mode>])

"r" (lecture seule) "w" (écriture seule)"r+" (lecture et écriture) "a" (ajout)

– (close [<logical-name>])– (rename <old-file-name> <new-file-name>)– (remove <file-name>)– (dribble-on <file-name>) (dribble-off)

• Lecture et écriture dans un flux d’entrée/sortie :– (read [<logical-name>])– (readline [<logical-name>])– (printout <logical-name> <expression>*)– (format <logical-name> <string> <expression>*)

Page 69: 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

69©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 1 2 3 4) 2)(3 4)

(deffunction coupe$ (?liste ?index) (if (eq ?index 0) then ?liste else (coupe$ (rest$ ?liste) (- ?index 1))))

CLIPS> (coupe$ (create$ 1 2 3 4) 2)(3 4)

Version LISP Version CLIPS

Page 70: 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

70©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Synthèse des constructeurs• Permettent de déclarer des connaissances (un

fichier CLP est constitué de constructeurs) :– deftemplate : déclaration d’un template– deffacts : déclaration d’un ensemble de faits initiaux– defrule : déclaration d’une règle– defglobal : déclaration d’une variable globale– deffunction : déclaration d’une fonction ou d’une

commande– defmodule : déclaration d’un module

• Concernent la couche COOL :– defclass : déclaration d’une classe par héritage– defmessage-handler : déclaration d’une méthode

d’instance– definstance : déclaration d’une instance– defmethod : déclaration d’une fonction générique

Page 71: 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

71©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 72: 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

72©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 :

<pattern-CE> ::= (<constraint> ... <constraint>) | (<deftemplate-name> (<slot-name> <constraint>)*)<constraint> ::= <constant> | ? | $? | ?<var-symbol> | $?<var-symbol>

(defrule operator-condition(data ?oper ?x)(value ?oper ?y)(test (> (abs (- ?y ?x)) 3))=>(assert (valid ?oper TRUE)))

<test-CE> ::= (test <function-call>)

Page 73: 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

73©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Écriture des conditions (2) Opérateurs booléens :

– Attention à l’utilisation du NOT !

– Le AND n’est utile qu’en combinaison avec le OR :

<not-CE> ::= (not <conditional-element>)<or-CE> ::= (or <conditional-element>+)<and-CE> ::= (and <conditional-element>+)

(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"))))

Page 74: 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

74©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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-CE> ::= (exists <conditional-element>+)

Page 75: 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

75©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Écriture des conditions (4) Condition universelle :

– Permet de tester si un ensemble de filtres est satisfait pour chaque occurrence d’un autre filtre :

<forall-CE> ::= (forall <conditional-element> <conditional-element>+)

(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)))

Page 76: 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

76©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Contraintes complexes

• Pratique et concis mais source d’erreurs !

– 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)))

Page 77: 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

77©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 78: 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

78©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 d’un 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 d’une même règle

Page 79: 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

79©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)))

Page 80: 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

80©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Arbre de discrimination

taille = 3

monkey

near

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

l’arbre :

Page 81: 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

81©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Réseau de jointures

• Vérifie les correspondances entre les variables :– Les nœuds regroupent 2 à 2 les prémisses d’une 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)))

Page 82: 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

82©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Première optimisation

• Factoriser les feuilles de l’arbre de discrimination :

(monkey near ?y)(goal monkey on ?x)(near ?x ?y)

?x

?y

(assert (goal emptyhanded monkey)))

?x

(assert (goal monkey near ?y)))

Page 83: 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

83©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)))

Page 84: 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

84©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

L = 3

monkey

near

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éA

rbre

de d

iscr

imin

ati

on

(near ?x ?y)

?x?y

Rése

au d

e join

ture

s

Page 85: 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

85©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 »S’il 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.

• L’efficacité d’un 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 :

Page 86: 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

86©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 l’agenda des tâches (profondeur d’abord)– Insertion à la fin de l’agenda des tâches (largeur d’abord)

– Stratégie Random :– Les règles de même intérêt sont insérées dans l’agenda de façon

aléatoire

– Stratégies Simplicity et Complexity :– Insertion en fonction de la spécificité croissante (simplicité d’abord)– Insertion en fonction de la spécificité décroissante (complexité

d’abord)• 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)))

Page 87: 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

87©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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) => ... )

Page 88: 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

88©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 :

4 3 3 3 2 21 2 2 1 1 1

1 1 nn

R6 R5 R1 R2 R4 R3

3 2 1 1 1 11 1 4 3 3 2

2 2 nn

R2 R3 R6 R5 R1 R4

Première prémisse

Lex

Page 89: 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

89©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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)

Page 90: 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

90©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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 <classe>

(is-a <super-classe>*)(role abstract|concrete)[(pattern-match reactive)](slot|multislot <attribut> [(type <type>)] ... )*)

CLIPS> (defclass DUCK (is-a USER) (role concrete))CLIPS> (make-instance of DUCK)[gen1]CLIPS> (make-instance Gaetan of DUCK)[Gaetan]

Page 91: 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

91©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

Hiérarchie des classes

OBJECT

PRIMITIVEUSER

INITIAL-OBJECTNUMBERINSTANCEADDRESSEMULTIFIELDLEXEME

FLOATINTEGER

INSTANCE-NAME

INSTANCE-ADDRESS

FACT-ADDRESS

EXTERNAL-ADDRESS

STRINGSYMBOL

Page 92: 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

92©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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

Page 93: 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

93©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

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))

Page 94: 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

94©

Jérô

me L

ehuen -

Univ

ers

ité d

u M

ain

e -

03

/10

/01

That’s all Folks !