Projet Loco

Précédent : Logiciels Remonter : Projet LOCO, Programmation en LOgique Suivant : Actions industrielles

Résultats nouveaux

Aspects langages

Programmation Concurrente avec Contraintes

Participants : Philippe Codognet , Jean-Hugues Réty , Nicolas Romero

Le paradigme CC classique est basé sur l'idée d'un ensemble de contraintes (store) global et est donc adapté aux architectures de type mémoire partagée mais pas aux systèmes distribués. Nous avons continué le développement d'un modèle de calcul concurrent par contraintes, appelé MCC (Message-based CC), adapté au cadre de la programmation distribuée.

Ce modèle a été présenté en janvier 1997 dans la thèse de Jean-Hugues Réty [6]. Il allie le calcul concurrent par contraintes des langages CC au niveau local à un mode de communication par messages issu du $\pi$ -calcul. Il intègre des notions de calcul local, de site et de communication distribués, ainsi qu'une notion de consommation de ressource qui fait grandement défaut, et tout particulièrement dans un cadre distribué, dans les langages CC.

La sémantique du modèle MCC a été clarifiée et étendue par la définition d'une relation de bi-similarité. D'autre part, les liens avec le $\pi$ -calcul ont été clarifiés par l'intermédiaire d'un encodage du $\pi$ -calcul dans le modèle MCC.

Contraintes et Réalité Virtuelle

Participants : Philippe Codognet , Nadine Richard

Le but était de gérer un ensemble de contraintes afin d'assurer une certaine cohérence au niveau d'une scène 3D tout au long de son animation. Pour cela, il a fallu d'abord définir les besoins propres à l'animation 3D temps-réel, puis déterminer la nature des contraintes pouvant porter sur des objets 3D animés. Nous avons ensuite choisi de considérer deux approches distinctes pour l'implémentation:

étendre VRML 2.0 pour y intégrer un mécanisme de contraintes, c'est-à-dire permettre à l'utilisateur de déclarer et résoudre des contraintes directement en VRML ;
intégrer les contraintes et leur résolution dans un langage de haut niveau (en l'occurrence Java) indépendamment de VRML.

La solution orientée Java semble intuitivement plus propre et plus robuste, mais aussi plus simple du point de vue de l'utilisateur, qui peut manipuler des objets 3D et des contraintes dans un véritable langage de programmation. Cependant, dans l'état actuel de la technologie VRML, il est encore difficile de se prononcer car seule la solution orientée VRML appliquée à des exemples très restreints donne des résultats visualisables.

Étude du parallélisme de données en Programmation en Logique

Participants : Arnaud Lallouet

Le parallélisme de données est un des meilleurs moyens permettant d'exploiter la puissance des machines massivement parallèles. Il n'a pourtant fait l'objet que de peu de travaux dans le domaine de la Programmation en Logique. Ceci tient au fait que celle-ci possède une interprétation parallèle naturelle en termes de parallélisme de tâches. Nous avons proposé une approche complémentaire qui consiste à manipuler directement des données vectorielles au sein d'un programme logique: l'interprétation parallèle naturelle se fait en termes de parallélisme de données.

Notre langage, appelé DP-LOG, possède deux caractéristiques originales visant à exploiter ce type de parallélisme:

1.: les données sont étendues de façon spatiale et distribuées sur l'architecture-cible;
2.: la communication se fait à l'aide d'une primitive qui permet de délocaliser la suite d'une preuve en un autre lieu.

Ces deux aspects sont harmonieusement intégrés au sein du langage logique et ont une lecture déclarative, un des avantages bien connus de la Programmation en Logique. Un autre aspect qu'il nous paraît important de signaler est l'expressivité de ce langage qui apporte des caractéristiques nouvelles par rapport à Prolog concernant le traitement des tableaux. Par son traitement natif et naturel des vecteurs, DP-LOG permet d'exprimer les algorithmes manipulant des tableaux de manière extrêmement simple, claire et concise. Nous avons présenté des sémantiques déclarative et opérationnelle pour ce langage dans [27].

Aspects domaines de contraintes et algorithmes de résolution

Contraintes sur les domaines finis

Participants : Philippe Codognet , Daniel Diaz , Yan Georget

Système `clp(FD)`

Notre travail de recherche s'est concentré sur la nouvelle version de clp(FD) : Calypso. La couche « programmation logique » (couche wamcc) a subi de nombreuses améliorations grâce à un schéma de compilation beaucoup plus efficace. En effet, au lieu d'utiliser le langage C comme langage intermédiaire pour la traduction, nous avons défini une machine virtuelle, i.e. un langage « mini-assembleur », indépendant de la machine, et dont le jeu réduit d'instructions assure une implantation aisée sur n'importe quelle architecture. Il en résulte des temps de compilations 5 à 10 fois plus courts que ceux obtenus avec l'actuelle version de clp(FD). Les exécutables produits sont également beaucoup plus petits en taille grâce à un système de librairie de prédicats prédéfinis qui permet de ne conserver que les prédicats réellement nécessaires. Enfin, la nouvelle version est conforme à la récente norme ISO de Prolog. En ce qui concerne la couche « contraintes sur les domaines finis », nous avons amélioré bon nombre de contraintes existantes et introduit de nouvelles contraintes/heuristiques prédéfinies. Citons en particulier l'apparition des méta-contraintes qui permettent à l'utilisateur de raisonner sur l'issue d'une contrainte (échec/réussite). Pour ce faire, nous avons étendu la primitive de base (X in r), utilisée pour définir de nouvelles contrantes, avec un mécanisme de retardement pour n'activer une contrainte que lorsqu'une condition est détectée. Ce travail est l'implantation des idées théoriques concernant la satisfaction de contraintes présentées dans le dernier chapitre de la thèse de Daniel Diaz. Le système ainsi obtenu a été retenu par la plupart des membres du projet ESPRIT DiSCiPl comme plateforme commune de développement. La version domaine public diffusée par ftp disponible sous le nom de Calypso.

Rétraction de contrainte

L'axe de recherche que nous avons récemment entamé en collaboration avec l'université de Pise (Francesca Rossi, Ugo Montanari) concerne l'extension du cadre PLC pour le traitement de la non-monotonie et de la réactivité. En effet, de nombreuses applications nécessitent un certain degré d'interaction, et donc de réaction, entre l'utilisateur et le système ou entre différentes parties du système, et il faut donc fournir des primitives pour un modèle sémantique et un modèle d'exécution pour gérer ces modifications incrémentalement et dynamiquement. Un algorithme incrémental efficace pour la rétraction de contraintes, dans le cadre des contraintes sur les domaines finis et plus particulièrement de l'approche RISC développée dans le système clp(FD), a été proposé et implanté [20]. Les premiers résultats sont prometteurs, et montrent des gains de performances intéressants par rapport à un algorithme classique de recalcul, pour des exemples classiques et réalistes d'applications.

Contraintes floues

Cet axe de recherche concerne la résolution de contraintes valuées, plus précisément à valeurs dans des demi-anneaux. Ce cadre englobe beaucoup d'extensions de la résolution de contraintes : contraintes hiérarchiques, floues, gestions d'hypothèses, etc. La base théorique a été fournie par l'Université de Pise (Stefano Bistarelli, Ugo Montanari, Francesca Rossi). Le travail effectué à l'INRIA a permis de proposer un schéma de compilation générique pour les contraintes valuées. De plus une intégration à clp(FD) est en cours de développement.

Contraintes Numériques

Participants : Frédéric Benhamou , Frédéric Goualard , Laurent Granvilliers , Nicolas Romero

Transformations symboliques et méthodes d'intervalles

L'efficacité des méthodes d'intervalles pour la résolution de contraintes non-linéaires réelles dépend de la syntaxe des contraintes. L'objet de ces travaux est de mettre en oeuvre des techniques de calcul formel tels que les factorisations, calculs de bases de Gröbner $\dots$ pour simplifier les expressions des fonctions réelles dans le sens d'une diminution du nombre de variables et d'occurrences de variables. Pour cela, nous avons défini un formalisme pour des algorithmes ``branch-and-prune'' implantant une coopération de méthodes symboliques et numériques. La réalisation en langage C d'un prototype de solveur a montré une convergence plus rapide des calculs d'intervalles après la transformation symbolique des contraintes initiales.

Ce thème a donné lieu aux publications [8,26,25].

Approche concurrente de la coopération de solveurs

Dans le cadre du projet CCOPS avec l'institut de recherche japonais AITEC, nous nous intéressons particulièrement, en collaboration avec l'équipe de parallélisme du LIFO dirigée par Gaétan Hains, à l'étude et à l'implantation d'une architecture concurrente permettant la coopération de solveurs de contraintes hétérogènes. L'état actuel de nos travaux dans ce domaine concerne plus particulièrement:

la définition d'un modèle d'exécution pour la coopération transparente de solveurs de contraintes. Un solveur peut être numérique ou symbolique, c'est-à-dire modifier un domaine (exemple des techniques d'intervalles) ou bien créer une contrainte (exemple des bases de Gröbner). Plus précisément, un solveur sur des contraintes est vu comme un ensemble d'opérateurs sur chaque contrainte, avec une stratégie de coopération entre eux. Nous utilisons la méthode BSP pour modéliser le parallélisme, ce qui permet de minimiser les communications et de calculer de manière fine les coûts engendrés par l'exécution en parallèle. Dynamiquement, des séquences de calculs (correspondant à l'application d'opérateurs) sont effectuées en parallèle localement sur chaque noeud et des barrières de synchronisation permettent les communications entre les noeuds pour rendre compte des calculs (intersection des domaines, création de nouvelles contraintes et association de ces contraintes à des solveurs existants, $\dots$ ).
la définition d'une spécification algébrique pour décrire le modèle d'exécution. Il faut pouvoir exprimer l'état global du store de contraintes (valeurs des domaines des variables, localisation des solveurs, localisation des variables $\dots$ ), les états locaux des calculs, le comportement (ie la sémantique) du système, $\ldots$
la définition d'un langage pour décrire les types de domaines dans le système (hiérarchie des types, conversions des types, intersections, unions $\dots$ ), les spécifications des solveurs de contraintes, les stratégies de résolution et de coopération, $\dots$

Stratégies de propagation

L'algorithme classique de propagation d'intervalles, dérivé de l'algorithme de Waltz, implante une approximation sur les intervalles de la consistance d'arc pour résoudre de façon approchée des Problèmes de Satisfaction de Contraintes réels. Il peut être décrit par l'application successive d'opérateurs de clôture, jusqu'à calculer le plus grand point fixe de ces opérateurs. Bien que l'algorithme soit confluent, l'ordre d'application des opérateurs influence notablement le temps T de résolution du problème. Dans le but de minimiser T, nous proposons d'implanter un algorithme de propagation d'intervalles où la stratégie d'application des opérateurs est guidée par des méthodes de recherche Tabou. Les résultats expérimentaux montrent une amélioration des temps de calcul pour un ensemble de tests proposés. Nous cherchons désormais à isoler les techniques nous permettant de réduire, -- voire d'annuler --, l'overhead dû aux calculs nécessités par la fonction de choix.

Ces travaux (préliminaires) ont donné lieu à la publication [31].

Implantation

Afin de pouvoir valider nos travaux sur les solveurs pour des langages de type PLC(Intervals), nous avons été amenés à modifier le solveur clp(FD) développé par Philippe Codognet et Daniel Diaz (voir (section ) afin d'en faire un langage de résolution de contraintes entières, booléennes et réelles utilisant la propagation d'intervalles. Le système ainsi obtenu, appelé DecLIC est présenté dans [24,15,34].

Les domaines des variables manipulées par DecLIC sont des intervalles dont les bornes sont des nombres flottants ; DecLIC supporte les intervalles ouverts ainsi que les intervalles fermés. Les opérateurs de contraction de clp(FD) pour les contraintes primitives ( $xy=z, x+y=z,\dots$ ) ont étés remplacés par des versions adaptées au calcul d'intervalles réels.

Bien que toujours capable de résoudre les mêmes problèmes que clp(FD), DecLIC ne possède pas l'efficacité de celui-ci pour tous les systèmes de contraintes sur les domaines finis. Ceci est dû au fait que DecLIC gère tous les domaines de façon uniforme (intervalles à bornes flottantes) ; de plus, il ne peut représenter des domaines non compacts, ce qui l'handicape énormément pour de nombreux problèmes en nombres entiers. La gestion des variables entières se fait par l'introduction d'une contrainte particulière is_integer/1 contraignant son argument à ne prendre que des valeurs entières. Ceci met clairement en évidence la complémentarité des travaux spécifiques sur les domaines finis autour de clp(FD) et ceux sur le traitement par intervalles des contraintes continues autour du langage DecLIC.

Dans le cadre de nos recherches sur les différentes consistances partielles utilisées dans les langages de type CLP(Intervals), nous avons été amenés à introduire dans DecLIC la Box-consistence [14]. DecLIC peut alors être considéré comme un système faisant coopérer trois solveurs différents :

1.: un solveur sur les entiers (modélisé par la contrainte is_integer/1) ;
2.: un solveur sur les réels utilisant la hull-consistency [9] : les contraintes complexes sont décomposées en contraintes primitives pour lesquelles la consistance est obtenue par l'utilisation de l'arithmétique relationnelle des intervalles ;
3.: un solveur sur les réels utilisant la box-consistency : les contraintes complexes ne sont pas décomposées, mais une contrainte n-aire sur les réels est transformée en n contraintes unaires sur les intervalles sur lesquelles ont applique des méthodes de Newton adaptées.

Actuellement, le choix de la consistance à utiliser pour traiter chaque contrainte se fait de manière syntaxique dans DecLIC. Nous avons cependant proposé dans [16] une méthode qui devrait nous permettre de choisir automatiquement quelle consistance utiliser en considérant les contraintes avec une granularité plus fine.

Nos recherches ont montré que la coopération de la hull-consistency et de la box-consistency était nécessaire pour obtenir les meilleurs résultats. Nous avons aussi montré que l'utilisation d'une variation de la box-consistency (appelée box(w)-consistency dans [15]) consistant à ne calculer qu'une approximation de la box-consistency permettait d'obtenir une accélération importante de la résolution de certains problèmes.

Aspects environnements

Système de débogage pour la PLC

Participants : Pierre Deransart , Christophe Aillaud , Frédéric Benhamou , Michel Bergère , Philippe Codognet , Daniel Diaz , Gérard Ferrand , Frédéric Goualard , Laurent Granvilliers , François Le Berre , Alexandre Tessier

Les approches traditionnelles du débogage reposent essentiellement sur l'analyse opérationnelle d'un programme à travers des systèmes de visualisation de traces plus ou moins sophistiqués. Cette approche s'avère impratiquable avec les langages PLC en raison de la grande combinatoire liée à la résolution de contraintes et de la complexité des états de calculs. Une approche originale a donc été développée au sein du projet DiSCiPl qui consiste à tirer profit au maximum de l'existence de deux sémantiques (déclarative et opérationnelle) clairement identifiées en PLC, désignée comme la « méthode DiSCiPl ».

La méthode consiste à distinguer dans le débogage, le « débogage de correction » et le « débogage de performance ». Dans le premier cas, il s'agit de détecter et corriger les erreurs liées à la sémantique déclarative des prédicats. Dans le second, ce sont les erreurs de stratégie de résolution et les erreurs de méthodes qui sont analysées. Une brève synthèse de cette approche est dans [37].

Le projet a procédé en plusieurs étapes:

1.

Analyse des besoins à partir d'un questionnaire élaboré avec les partenaires industriels (cf [22]).

2.

Une étude des outils possibles [36], ainsi qu'une étude théorique de leur combinaison [18]. Il ressort en effet de cette étude que la difficulté et l'originalité de l'approche repose plus sur l'élaboration de bonnes combinaisons plutôt que de la puissance d'un outil unique.

Trés schématiquement, trois catégories d'outils sont prises en compte:

des outils d'analyse statique, incluant un systéme de typage pour la PLC,
des outils de débogage déclaratifs (utilisant la structure prédicative des programmes PLC) et d'analyse des contraintes (utilisant des « S-boxes » pour structurer à la demande des ensembles de contraintes),
des outils d'analyses du controle et de profilage, avec des outils de visualisation des états de variables, permettant l'analyse de performance.

3.

Des analyses approfondies des outils dont nous avons plus particulièrement la charge au sein du projet (voir ci-dessous: diagnostic déclaratif et diagnostic des contraintes).

4.

Une première mise en oeuvre pratique et expérimentation avec notre partenaire espagnol (UPM) concernant la visualisation du contrôle.

Les outils de débogage sont destinés à être intégrés, entre autres, à la plateforme Calypso développée par le projet.

Diagnostic Déclaratif

Participants : Gérard Ferrand , François Le Berre , Alexandre Tessier

Les travaux concernant le « diagnostic déclaratif d'erreur » [29,7] ont été approfondis et ont conduit à une nouvelle présentation uniforme et simplifiée des algorithmes de recherche d'erreur dans le cas de réponses erronées ou manquantes [23], [21].

La sémantique des programmes PL est expliquée par une extension de la vision grammaticale aux programmes PLC et à été revisitée en termes de sémantique positive et sémantique négative [33] autorisant une approche duale pour les deux types de diagnostic [38].

Ces résultats servent de base théorique aux implantations en cours de développement dans le projet DiSCiPl (section ).

Diagnostic des contraintes

Participants : Frédéric Benhamou , Frédéric Goualard , Laurent Granvilliers

Nous nous sommes plus spécifiquement intéressés dans cette partie à définir des méthodes permettant de déboguer un programme PLC par une inspection du store créé lors de son exécution. En nous basant sur nos précédents travaux, nous avons introduit les notions de système de contraintes hiérarchique et de S-box : une vision traditionnelle du store ( $\S_1$ ) est celle consistant à l'assimiler à un réseau de contraintes liées entre elles par des dépendances dues à des variables partagées. Nous proposons de remplacer la notion de « réseau de contraintes » par celle plus générale de « réseau de S-boxes » ( $\S_2$ ), une S-box étant soit une contrainte du store primitif $\S_1$ , soit une conjonction de contraintes de $\S_1$ et/ou de S-boxes. On peut ainsi créer une arborescence de S-boxes agissant comme des « macros »-contraintes (en particulier, chaque S-box est un mini réseau de contraintes dont la relaxation se fait de façon atomique) à partir de l'ensemble de contraintes posées par le programme à déboguer. Du fait des propriétés des opérateurs de contraction [9] modélisant la sémantique opérationnelle des contraintes utilisées, nous pouvons montrer simplement que la structuration du store de départ en une arborescence de S-boxes préserve la sémantique déclarative approchée du programme inspecté.

La structuration du store en une arborescence de S-boxes est un premier pas vers sa maîtrise. En particulier, nous montrons dans [17] qu'il est possible de définir un outil de débogage tirant parti de cette structuration pour masquer temporairement à l'utilisateur des ensembles de contraintes (diminution de la complexité globale du store) afin de lui permettre de n'observer qu'un sous-ensemble de contraintes de taille raisonnable. Nous introduisons aussi la notion de zoom consistant à décomposer une S-box en ses composantes, ou au contraire à (re-)composer une S-box à partir de S-boxes et/ou de contraintes de $\S_1$ ; cela permet de modifier aisément la « granularité » des objets manipulés.

Nos travaux sur les S-boxes sont décrits dans [17,36,32]. Ces résultats servent de base théorique aux implantations en cours de développement dans le projet DiSCiPl (section ).

Validation

Participants : Pierre Deransart , Pascal Chambre , Gérard Ferrand , Bernard Malfon

Vérification statique de propriétés et diagnostic d'erreur sont intimement reliés. Dans le premier cas, le succès d'une preuve assure qu'il n'y a pas pas d'erreur, tandis que son échec assure seulement l'existence d'une erreur, sans nécéssairement la localiser avec précision (par exemple une violation de type lors de la compilation). Le diagnostic part d'un symptome (de résultat erroné ou inexistant), obtenu à partir d'une exécution, qui assure l'existence d'une erreur. Le « diagnostiqueur » va alors tirer parti de la connaissance du calcul ayant conduit au résultat erroné pour localiser avec précision l'erreur du programme.

Si les rapports entre validation et diagnostic semblent intuitivement évidents, leur analyse précise n'a jamais vraiment été faite. De premiers résultats utilisant l'interprétation abstraite sont parus dans [18]. Leur intérêt principal est d'aider à comprendre comment différentes approches du diagnostic d'erreur peuvent être combinées d'une manière pratique effective.

Hyper Programmation Logique

Participants : Pierre Deransart , Ali Ed-Dbali , José de Siqueira , Khaled El Qorchi

Le projet « HyperPro » développé en collaboration avec l'Université Fédérale de Minas Gerais au Brésil, vise à intégrer la puissance de la documention hypertexte avec les méthodes de développement de programmes avec contraintes mises au point dans notre équipe.

Le but est de développer un système expérimental dans lequel un programme (suite de clauses) est développé en même temps que les commentaires de manière interactive ; suite à quoi le système permet de produire un texte documenté (introduction, clauses avec commentaires et références, et index). Le système est construit à partir du système Thot développé à l'INRIA (projet OPERA).

Un cahier des charges d'un premier prototype a été établi en commun [35], puis un prototype est en cours de développement par Ali Ed-Dbali et Khaled El Qorchi. Une partie des fonctionnalités est développée par l'équipe brésilienne.