Projet : LOCO

previous up next contents
Précédent : Résultats nouveaux Remonter : Résultats nouveaux Suivant : Aspects domaines de contraintes et


Sous-sections


   
Aspects langages

   
Sémantique de la programmation en logique avec contraintes



Participants : Gérard Ferrand, Alexandre Tessier.

Nous proposons une nouvelle approche de la sémantique des programmes logiques avec contraintes en terme de sémantique positive et sémantique négative [[13],[31],[22]].

Dans ce cadre naturel et élégant les résultats connus sont retrouvés et de nouveaux résultats sont donnés. Par exemple, on retrouve les résultat de correction et complétude de la sémantique positive et on ajoute les résultats de correction et complétude de la sémantique négative. De plus nous avons identifié pour l'ensemble de ces résultats les hypothèses nécessaires sur le solveur de contraintes en termes de correction/complétude. Au passage on a établi un résultat intéressant sur la complétude de la négation par l'échec qui nécessite un solveur complet. Or la majorité des solveurs implantés sont incomplets! Ce qui confirme l'intérêt de recherches pour d'autres types de négation comme, par exemple, la négation constructive.

   
Typage pour la PLC



Participants : Pierre Deransart, Valentin Bonnard, Marco Comini.

Pierre Deransart a travaillé avec Jan Ma\luszynski sur une nouvelle approche du typage baptisée ``soft typing''. Il s'agit de pouvoir combiner le fait que la PLC possède un typage prescriptif inhérent aux domaines de contraintes utilisés, avec une approche descriptive, basée sur la génération automatique de type telle que développée à l'université de Linkoeping.

L'approche repose sur une adaptation de la génération de type mise au point par Gallagher et de Waal pour la programmation en logique à la PLC. Un système de type pour le système CHIP V5 de Cosytec a été développé à Linkoeping. Nous l'avons transporté sur Calypso avec Valentin Bonnard [[21]] et Marco Comini.

Nous avons alors étudié les rapports entre les buts qu'un système de type cherche à atteindre et le problème de correction partielle d'un programme (CLP) [[12]]. Plusieurs notions de ``type-correction'' ont été identifiées en se référant aux concepts connus de correction partielle. Cela nous a amené à attacher à chaque prédicat un ``mode'' et un ``type'', les deux ensembles constituant en fait le type du prédicat. Le ``soft typing'' repose sur l'idée qu'un utilisateur n'est intéressé, ainsi qu'une certaine ``tradition'' le veut en programmations en logique, qu'à spécifier des types seulement pour une partie des prédicats. Les types des autres prédicats sont alors obtenus par inférence automatique. L'approche utilisée ici est l'interprétation abstraite et l'utilisation de shémas de preuve par induction. Nous avons montré que certaines propriétés sont bien capturées (avec une certaine approximation cependant) par l'approche descriptive, alors que l'approche prescriptive en capture d'autres.

L'étude entreprise permet maintenant d'entrevoir comment on pourrait essayer de combiner les approches: une approche prescriptive incomplète et peu contraignante, mais imprécise, avec une approche descriptive mais complète, permettant à l'utilisateur de boucher les trous en quelque sorte, à la demande. Le système de type descriptif en cours de dévelopement pour Calypso nous donnera une base solide pour la réflexion et l'expérimentation.

Système Calypso



Participant : Daniel Diaz.

Notre travail de recherche s'est concentré sur la finition du système Calypso. En ce qui concerne la couche ``Prolog'' nous avons d'une part peaufiné le niveau de compatibilité avec la norme ISO de Prolog et d'autre part intégré de nouvelles extensions telles que l'interfaçage avec le langage C, l'interfaçage avec le système d'exploitation sous-jacent, la communication par sockets. Toutes ces extensions permettent désormais d'utiliser Calypso pour le développement d'applications ``professionnelles'' (avec de la gestion d'erreurs, des interfaces graphiques). Ceci était nécessaire à la bonne réalisation des logiciels au sein du projet ESPRIT Discipl puisque Calypso a été retenu comme plateforme de développement par la plupart des membre de ce projet. En ce qui concerne la couche ``contraintes sur les domaines finis'' nous avons amélioré le résolveur de contraintes et ajouté de nouvelles contraintes prédéfinies. La version courante de Calypso est une beta-version disponible sur les plateformes suivantes: sunos/sparc, solaris/sparc et linux/ix86. Cette version est distribuée par ftp sur le site de l'INRIA. Elle est actuellement testée par une dizaine de personnes (au sein de LOCO et par des extérieurs). Nous travaillons actuellement sur la rédaction de la documentation (plus de 170 pages ont déjà été rédigées). La version courante est désormais très proche de la version finale 1.0 prévue pour le début d'année 1999. Cette version incluera également un portage pour les plateformes Windows 95, Windows 98 et Windows NT.

Approche concurrente de la coopération de résolveurs



Participants : Frédéric Benhamou, Philippe Codognet, Laurent Granvilliers, Nicolas Romero.

Un contrat de recherche d'un an de l'institut de recherche japonais AITEC a permis à Frédéric Benhamou de mettre sur pieds le projet CCOPS (Concurrent Cooperative Parallel Solvers).

Nous nous sommes penchés, en collaboration avec Gaétan Hains de l'Université d'Orléans et Quentin Miller de l'Université d'Oxford, sur la réalisation d'une architecture concurrente permettant la coopération de résolveurs de contraintes hétérogènes. Nous nous sommes particulièrement attachés à formaliser la coopération et la parallélisation de résolveurs de contraintes pour des systèmes à mémoire partagée et à permettre l'intégration de résolveurs pré-existants.

Un ré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 résolveur de contraintes est vu comme un ensemble d'opérateurs de transformation des contraintes ou des domaines, la coopération résultant de l'application de différents opérateurs. L'exécution en parallèle est inspirée du modèle BSP (Bulk Synchronous Parallelism), qui permet de calculer de manière fine les coûts engendrés par l'exécution en parallèle. La résolution d'un système de contraintes consiste à répartir les données (opérateurs et variables) sur les noeuds, puis à calculer sur chaque noeud de la façon suivante : sélection des opérateurs à appliquer, récupération des données distantes, application des opérateurs, combinaison des résultats et mise à jour des données. Ce calcul est itéré un nombre de fois donné, ou jusqu'à ce que les domaines soient fixes.

Cette spécification a été implantée dans le système Bs-Solve, qui est une bibliothèque écrite en KL1 (avec KLIC, le compilateur KL1 de l'AITEC) et en C permettant d'intégrer des résolveurs pré-existants et d'écrire en KL1 des stratégies de coopération entre eux. Nous l'avons utilisé pour paralléliser deux algorithmes classiques, l'algorithme de consistance de Waltz pour les domaines continus, et le calcul de bases de Gröbner d'ensembles de polynômes, en utilisant deux résolveurs développés en C.

Ces recherches nous ont notamment permis, en comparant des exécutions séquentielles et parallèles, de mettre en avant des problèmes, dûs à la répartition des données, d'équilibrage et de ralentissement de la convergence de l'algorithme de Waltz (sur certains exemples).

La proposition, les rapports du projet CCOPS et le système Bs-Solve sont disponibles à l'URL:
http://www.icot.or.jp/AITEC/FGCS/funding/itaku-H9-index-E.html.

Système Cosinus



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

Les transformations symboliques des contraintes pour réduire les problèmes de dépendance des variables (diminution du nombre d'occurrences de variables) sont un facteur d'accélération et de précision des calculs d'intervalles futurs. Nous avons étendu dans [[3]] le modèle de coopération de résolveurs de contraintes numériques proposé en 1996 par Frédéric Benhamou: les calculs symboliques génèrent des CSP disjonctifs pour lesquels les calculs d'intervalles sont plus précis que pour le CSP initial. Ce formalisme a été instancié par des calculs de bases de Gröbner créant des redondances, des factorisations et substitutions de termes dans les contraintes polynomiales, des divisions de contraintes en forme factorisée, et des méthodes d'intervalles. Une implantation dans notre résolveur Cosinus montre l'efficacité de l'algorithme pour un ensemble de tests standards [[4]].

La programmation de stratégies de coopération de résolveurs est souvent une tâche fastidieuse. Pour la simplifier, nous avons exploré la mise en oeuvre d'un langage déclaratif et expressif réalisant une interface avec les outils implantés dans le résolveur Cosinus. Il permet la description des données d'un CSP (contraintes, domaines), comme le langage Numerica, et la programmation des stratégies. Actuellement, l'interface est spécifiée de façon fonctionnelle et une stratégie est l'application séquentielle de primitives définies par le langage. Une introduction à Cosinus a été réalisée dans [[8]] et présentée dans [[9],[2]].

  
Design et implémentation d'OpAC



Participants : Frédéric Benhamou, Frédéric Goualard.

Nous avons créé l'année dernière un système de résolution de contraintes étendant clp(FD) et permettant de résoudre des systèmes de contraintes sur les réels, les booléens et les entiers. Ce logiciel baptisé DecLIC nous a servi de plate-forme d'essais pour nos recherches dans le domaine des coopérations de méthodes de résolution. Dans le cadre du réseau formation-recherche franco-portuguais, il a aussi été utilisé par Jorge Cruz, un étudiant en thèse d'Informatique à l'universidade nova de Lisboa pour des travaux sur des problèmes de dégénérescence nerveuse des extrémités (bras, jambes) et par Marc Christie, un étudiant en DEA d'Informatique pour le prototypage d'une application de placement de caméra (cf. section 6.2.3). L'expressivité du langage Prolog, base de clp(fd) et donc de DecLIC, a permis à ces personnes d'écrire rapidement des programmes résolvant leurs problèmes en utilisant les fonctionnalités offertes par DecLIC. En contrepartie, l'extension du système requiert une connaissance de la machine abstraite de Warren (WAM) à la base du compilateur Prolog, ainsi que des spécificités de clp(fd). En pratique, un tel apprentissage s'avère trop coûteux en temps pour qu'un utilisateur puisse ajouter lui-même de nouvelles fonctionnalités. Il doit donc, soit se tourner vers les implémenteurs du système, soit programmer en Prolog (niveau où il ne dispose que d'un accès limité aux caractéristiques du solveur).

Afin de pallier cet inconvénient, nous avons développé OpAC (Open Architecture for Constraints), une librairie C ++ pensée dès l'origine pour être aisément extensible par les utilisateurs potentiels et intégrable dans tout logiciel ayant besoin de résoudre des contraintes. OpAC offre six classes de base indispensables à la résolution de contraintes par propagation de domaines :

1.
la classe nombre, définissant le type des valeurs que peut prendre une variable ;
2.
la classe domaine ;
3.
la classe contrainte, définissant la forme et la sémantique des contraintes utilisées ;
4.
la classe solveur chargée de gérer les variables du système de contraintes et de découper leurs domaines jusqu'à ce que l'on obtienne la précision souhaitée ;
5.
la classe propagateur gérant la ré-invocation des contraintes dont certaines des variables ont été modifiées.

Ces classes peuvent être dérivées par l'utilisateur de la librairie au gré de ses besoins. Il peut ainsi utiliser des variables dont le domaine est représenté par des nombres flottants en précision arbitraire, ou par des double classiques, changer la stratégie de propagation des modifications de domaines. La figure 1 montre les classes dérivées actuellement implémentées en standard dans OpaC ainsi que celles qui le seront à court terme. Nous prévoyons aussi de créer un langage de haut niveau au-dessus d'OpAC permettant d'exploiter ses capacités en résolution de contraintes sans avoir à programmer en C ++.

Comme on le verra dans la section 6.2.3, OpAC semble remplir les objectifs ayant présidés à sa naissance puisqu'il a déjà été utilisé et étendu dans le cadre d'une collaboration avec des membres de l'équipe ``Image'' de l'Institut de Recherche en Informatique de Nantes.


  
Figure 1: Hiérarchie de classes dans OpAC
\includegraphics{hierarchie.eps}

Contraintes et conception de mondes virtuels



Participants : Philippe Codognet, Nadine Richard.

Le projet InViWo (Intuitive Virtual Worlds), qui fait l'objet de la thèse de Nadine Richard, a pour objectif de concevoir un outil intuitif de création de mondes virtuels, et plus particulièrement de proposer un langage de description de comportements d'agents vivant dans des environnements virtuels en 3D. Cet outil est destiné à des non-programmeurs. Le projet se composera de trois parties distinctes :

Une maquette de la bibliothèque de programmation des agents est en cours de réalisation. Elle permettra en particulier de valider les choix d'implémentation concernant le gestionnaire d'exécution. Il faudra ensuite s'intéresser plus précisément au coeur du projet, c'est-à-dire au langage déclaratif de description de comportements.

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



Participant : 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 Programation 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 qui nous parait 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 simple, claire et concise. Ces résultats sont rassemblés dans [[5]].

De plus, nous avons adapté le langage au modèle d'exécution BSP (Bulk Synchronous Parallelism) dans [[18]] afin préciser la sémantique opérationnelle. Ceci a permis d'introduire dans le langage les limitations rencontrées dans la pratique telles que les lieux explicites ou les communications atomiques.



previous up next contents
Précédent : Résultats nouveaux Remonter : Résultats nouveaux Suivant : Aspects domaines de contraintes et