4.3 Carte de compilation d’IA
4.3.3 Requêtes et transformations
L CO VA MC CE IM EQ SE MX CX CT ME
IA ◦ ◦ √ ◦ ◦ ◦ ◦ ◦ ◦ ◦ ◦
FIA √ ◦ √ √ ◦ ◦ ◦ √ √ ◦ √
Tab. 4.1 : Résultats sur les requêtes ;√signifie « satisfait », et◦ signifie « ne satisfait pas, sauf si P = NP ».
L CD TR FO SFO EN SEN ∨C ∨BC ∨clC ∧C ∧BC ∧tC
IA √ ◦ ◦ √ ◦ √ √ √ √ √ √ √
FIA √ √ √ √ ◦ ◦ √ √ √ ◦ ◦ √
Tab. 4.2 : Résultats sur les transformations ;√signifie « satisfait », et◦ signifie « ne satisfait pas, sauf si P = NP ».
Théorème 4.3.14. Les résultats de compacité présentés dans les tableaux 4.1 et 4.2
sont démontrés.
Une grande partie des démonstrations provient directement de résultats de la carte de compilation existante [théorème 1.4.15]. Par exemple, le fait qu’IA ne satisfait aucune requête excepté le model-checking vient du fait que c’est le cas pourBDDSBB ; puisqueBDDSBB ⊆ IA, IA ne peut supporter aucune requête que ne supporte pas BDDSBB , comme l’indique la proposition 1.2.17.
Cela rendIA faible pour une vaste majorité des requêtes. En imposant la conver- gence, on rend polynomiales la plupart des requêtes, y comprisCOetMX, qui sont particulièrement importantes dans notre contexte. Il est notable que malgré cette restriction, la plupart des transformations restent polynomiales, notamment l’oubli de variables. De ce point de vue, le « profil » (en termes de compilation de connais- sances) deFIA est proche de celui de DNNF, FIA n’étant cependant pas un langage décomposable.
Notons que la transformation de négation (¬C) n’apparaît pas dans la table. Cela est dû à l’expressivité d’IA, qui n’est pas fermée pour la négation, étant donné que seuls les intervalles fermés sont autorisés.
Remarquons en passant que le fait que les IAs et FIAs réduits ne soient pas canoniques — contrairement aux OBDDs — est un corollaire de ce théorème : en effet, s’ils étaient canoniques,EQserait polynomiale.
* * *
Ayant présenté les aspects théoriques des automates à intervalles, nous passons dans le chapitre suivant au côté plus pratique de la compilation versIA, et plus précisément versFIA.
5
Construction
d’automates à intervalles
Nous avons vu qu’en théorie, les automates à intervalles convergents permet- taient de manipuler efficacement des variables à domaines continus ou énumérés. On peut donc adapter des approches existantes de « planification avec compila- tion » [§ 2.3], et en particulier celles que nous avons décidé d’étudier [§ 3.1], à l’utilisation de telles variables. Ainsi, il serait possible d’embarquer une politique de décision [§ 3.3.2.1] ou une table de transition [§ 3.3.2.2] pour permettre à un système autonome de prendre des décisions, sans devoir s’appuyer sur log2(n) va- riables booléennes pour représenter chacune des variables continues dont on aurait discrétisé le domaine en n valeurs. Mais comment obtenir un FIA représentant une politique de décision ou une table de transition donnée ? Avant de les utiliser en pratique, nous devons étudier l’étape de compilation [§ 1.5.2].
À cette fin, nous nous penchons dans ce chapitre sur les diverses façons de construire des automates à intervalles convergents. Nous présentons tout d’abord le langage d’entrée, dans lequel les problèmes sont initialement représentés, celui des réseaux de contraintes continus [§ 5.1]. Nous détaillons ensuite la compilation
bottom-up [§ 5.2] puis la compilation par trace d’un solveur [§ 5.3].
5.1
Réseaux de contraintes continus
Comme indiqué à la section 1.5.2, un moyen naturel de représenter les fonc- tions booléennes est le réseau de contraintes : un modèle d’une fonction boo- léenne est une solution du réseau de contraintes associé. Quand il porte sur des variables réelles, le problème de satisfaction de contraintes est généralement appe- lé CSP continu [SF96]. Nous utiliserons une terminologie similaire, bien que nous
n’autorisions pas n’importe quelle variable réelle, mais seulement celles qui sont R-pavables.
Définition 5.1.1. Un réseau de contraintes continu (CCN, continuous constraint network) est un réseau de contraintes Π =⟨V, C ⟩ tel que V ⊆ T .
Transformer un CCN en FIA n’est pas une tâche triviale. Notons que la compi- lation en automate à intervalles comporte une importante différence avec la com- pilation en OBDD ; chaque contrainte d’un CN booléen est en effet représentable par un OBDD, ce qui permet notamment une compilation bottom-up, alors que l’incomplétude d’IA [proposition 4.1.6] ne le permet pas directement. Ainsi, des contraintes très simples telles que x < 1 ou x = y ne peuvent être représentées exactement par des IAs.
La solution que nous avons retenue est l’utilisation d’un solveur de contraintes
basé sur les intervalles, c’est-à-dire un outil conçu pour calculer une approxima-
tion de l’ensemble solution d’un CCN en divisant récursivement les domaines des variables en plusieurs morceaux. Nous avons utilisé le solveur RealPaver [GB06]. Sa sortie consiste en une liste de boîtes, qui sont directement compatibles avec le cadre des automates à intervalles.
RealPaver peut garantir qu’aucune solution n’est perdue, c’est-à-dire que toute solution du CCN est comprise dans au moins une des boîtes renvoyées. Sous cer- taines hypothèses, il est aussi capable de vérifier si l’ensemble de solutions est exac-
tement l’union des boîtes renvoyées. Il utilise pour cela une distinction entre deux
types de boîtes, les extérieures, qui peuvent potentiellement contenir des instancia- tions non solutions, et les intérieures, qui ne contiennent que des solutions. Nous avons décidé d’ignorer cette distinction, les automates à intervalles ne permettant de représenter qu’un seul type d’ensemble.
En résumé, l’incomplétude des automates à intervalles nous force à utiliser des approximations des fonctions booléennes que nous voulons compiler. Nous nous appuyons sur RealPaver pour calculer cette approximation, et nous contentons de compiler des automates à intervalles représentant les unions de boîtes renvoyées par RealPaver.