Au coeur de la consistance d`arc
Transcription
Au coeur de la consistance d`arc
Actes JNPC’03 Au coeur de la consistance d’arc Christophe Lecoutre Frédéric Boussemart Fred Hemery CRIL-CNRS FRE 2499 rue de l’universite, SP 16 62307 Lens cedex lecoutre,boussemart,hemery @cril.univ-artois.fr Résumé La consistance d’arc reste l’une des propriétés fondamentales du problème de satisfaction de contraintes. Parmi tous les algorithmes qui ont été développés pour établir cette propriété, AC3, et plus précisément les algorithmes plus élaborés de la même famille tels que AC2001/AC3.1 ou AC3.2, reste incontournable. Dans ce contexte, nous présentons trois variantes pour les algorithmes de la famille de AC3 et nous nous intéressons à l’ordre des révisions appliquées par celles-ci. Ces variantes correspondent respectivement à une gestion des révisions sur la base de variables, de contraintes et d’arcs. Pour ces différentes variantes, nous proposons plusieurs heuristiques originales de choix de révision basées sur la proportion de valeurs éliminées des différents domaines et sur la taille courante du domaine des différentes contraintes. Les résultats expérimentaux montrent qu’utiliser ces heuristiques avant et/ou au cours de la recherche d’une solution s’avère particulièrement efficace en terme de tests de consistance. Toutefois, il apparaı̂t que, à ce stade de l’étude, seule la variante orienté-variable permette de concrétiser assurément ce gain au niveau du temps de calcul. 1 Introduction La consistance d’arc reste l’une des propriétés fondamentales des problèmes de satisfaction de contraintes. Elle garantit que toute valeur du domaine d’une variable possède au minimum un support dans toute contrainte. Cette propriété peut être établie avant la recherche d’une solution et/ou pendant cette recherche. De nombreux algorithmes ont été développés pour établir la consistance d’arc. L’un des tous premiers est l’algorithme AC3 [Mackworth, 1977]. Cet algorithme, à gros grain, consiste à appliquer des révisions successives de couples , appelés arcs, constitués d’une contrainte et d’une variable sur laquelle porte . D’autres algorithmes tels que AC4 [Mohr et Henderson, 1986], AC6 [Bessiere, 1994] et AC7 [Bessiere et al., 1999] ont été proposés ultérieurement. Ces algorithmes, à grain fin, consistent à appliquer des révisions successives de triplets constitués d’un arc et d’une valeur appartenant au domaine de la variable . En théorie, AC3 admet une complexité temporelle dégradée vis à vis des algorithmes à grain fin : pour AC3 et pour AC4, AC6 et AC7 où et représentent respectivement le nombre de contraintes et le nombre de valeurs par domaine. En pratique, AC3 ne 233 234 peut pas toujours rivaliser en efficacité avec AC6 et AC7. Cependant, sa simplicité et son aptitude à être intégré facilement dans un solveur, ont favorisé son utilisation. Par ailleurs, des extensions récentes lui ont été apportées, qui tout en préservant la simplicité du modèle, ont permis d’atteindre le niveau d’efficacité des algorithmes à grain fin (en ramenant, en particulier, la complexité théorique temporelle en ). Celles-ci correspondent aux algorithmes AC2000 [Bessiere et Regin, 2001], AC2001/AC3.1 [Bessiere et Regin, 2001; Zhang et Yap, 2001], AC3 [van Dongen, 2002], AC3.2 [Lecoutre et al., 2003] et AC3.3 [Lecoutre et al., 2003] que l’on peut considérer comme appartenant à la famille de AC3. Au niveau des bonnes propriétés de ces différents algorithmes, il est possible d’effectuer un parallèle [Bessiere et Regin, 2001] entre AC2001/AC3.1 et AC6 et un autre [Lecoutre et al., 2003] entre AC3.3 et AC7. Il semble donc que les algorithmes de la famille de AC3 puissent être considérés comme faisant partie aujourd’hui des algorithmes incontournables pour établir la consistance d’arc 1 . Dans ce papier, nous nous intéressons à l’ordre des révisions qui sont appliquées successivement par AC3. Nous présentons tout d’abord trois variantes de AC3, à savoir les variantes orienté-arc, orienté-variable et orienté-contrainte. La première est classique, la seconde correspond à l’algorithme appelé AC8 [Chmeiss et Jegou, 1998], et la dernière est originale. Même si ces trois variantes sont fondamentalement équivalentes, nous allons mettre en évidence leur impact vis à vis de l’ordre des révisions à appliquer. A notre connaissance, les seules références portant sur des heuristiques de choix de révisions sont [Wallace et Freuder, 1992; Gent et al., 1997; van Dongen, 2002] dans le cadre de l’utilisation de la variante AC3 orienté-arc pour des problèmes binaires, et [Régin, 1995] dans le cadre de l’utilisation d’algorithmes à grain fin. Pour notre part, nous nous intéressons à de telles heuristiques par rapport à l’utilisation des trois variantes, avant et/ou au cours de la recherche, pour des problèmes d’arité quelconque. Nous proposons, en particulier, des heuristiques originales basées sur la proportion de valeurs éliminées des différents domaines et sur la taille courante du domaine des différentes contraintes. Puis, après un tour d’horizon des travaux connexes aux nôtres, nous présentons les résultats de nos expérimentations sur des problèmes aléatoires, académiques et réels. 2 Préliminaires Dans cette section, nous introduisons quelques définitions et notations utilisées dans la suite du papier. Définition 1 Un problème de satisfaction de contraintes (CSP pour Constraint Satisfaction Pro où : blem) est un couple est un ensemble fini de variables tel que chaque variable – possède un domaine représentant l’ensemble des valeurs pouvant être assignées , à est un ensemble fini de contraintes tel que chaque contrainte – ! " correspond à une relation représentant l’ensemble des tuples autorisés pour les variables #$&% liées par la contrainte . L’arité d’une contrainte est le nombre de variables liées par celle-ci, i.e., le nombre de variables dans #&% . Une contrainte binaire lie deux variables. Nous appellerons domaine d’une contrainte le produit cartésien des domaines associés aux variables de la contrainte. Sans 1 En fait, par souci de simplicité, la plupart de ce qui suit concerne directement AC3 mais peut être adapté sans aucun problème à ses différentes extensions. 235 perte de généralité, nous considérerons que tout ensemble de variables #&% associé à une contrainte est ordonné. Ainsi, il est possible d’obtenir la position &% d’une variable dans #$&% et la variable #$ dans #$&% . Une solution est l’affectation d’une valeur à l’ensemble des variables du problème de telle sorte que chaque contrainte soit satisfaite. Une solution garantit l’existence d’un support dans chaque contrainte. Définition 2 Soit une contrainte d’arité , un -uplet (ou tuple) représente une liste de valeurs indexée de à , notées ici . Un tuple est dit : – valide pour ssi #$ , – autorisé par ssi !! , – un support (courant) de ssi est valide et autorisé. On dit qu’un tuple est un support de dans lorsque est un support de tel que . Déterminer si un tuple est autorisé par une contrainte s’appelle un test de consistance (ou test de contrainte). La dureté d’une contrainte correspond, soit à la proportion de tuples non autorisés, soit à la probabilité qu’un tuple soit non autorisé. La densité d’un CSP, où toutes les contraintes sont d’arité , correspond à la proportion . Un CSP est dit satisfiable ssi il admet une solution. Résoudre un CSP consiste soit à déterminer son insatisfiabilité, soit à trouver une solution (ou plus). Les méthodes de recherche complètes utilisent, en règle générale, un algorithme de recherche en profondeur d’abord avec gestion de retours-arrières, où à chaque étape de la recherche, une assignation de variable est effectuée suivie par un processus de filtrage appelé propagation de contraintes. Dans la plupart des cas, la propagation de contraintes consiste à éliminer des valeurs du domaine des différentes variables. Actuellement, l’un des algorithmes de recherche les plus performants est l’algorithme MAC [Sabin et freuder, 1994; Bessiere et Regin, 1996] qui consiste à maintenir la propriété de consistance d’arc à chaque étape de la recherche. &% Définition 3 Soit un CSP et un couple composé d’une variable de et d’une valeur $ . est dit consistant par rapport à une contrainte de ssi soit #$&% soit il existe un support de dans . est dit consistant ssi est consistant par rapport à toutes les contraintes de . est arc-consistant ssi tous les couples formés à partir de sont consistants. 3 Algorithmes AC3 Dans cette section, nous présentons l’algorithme de base pour la consistance d’arc, à savoir AC3 [Mackworth, 1977]. Même si cet algorithme a subi la concurrence sévère d’algorithmes tels que AC4 [Mohr et Henderson, 1986], AC6 [Bessiere, 1994] et AC7 [Bessiere et al., 1999], sa simplicité, ainsi que son efficacité relative (e.g., [Wallace, 1993]) lui ont assuré une place de choix dans de nombreuses implémentations. De plus, des améliorations récentes lui ont été apportées, lui assurant semble-t-il une certaine pérennité. Celles-ci correspondent aux algorithmes AC2000 [Bessiere et Regin, 2001], AC2001/AC3.1 [Bessiere et Regin, 2001; Zhang et Yap, 2001], AC3 [van Dongen, 2002], AC3.2 [Lecoutre et al., 2003] et AC3.3 [Lecoutre et al., 2003]. Même si ce qui suit porte essentiellement sur AC3 par souci de simplicité, cela peut être adapté sans aucun problème à ses différentes extensions. AC3 est un algorithme à gros grain, c’est à dire, un algorithme dont le principe consiste à appliquer des révisions successives de couples , appelés arcs, composés d’une contrainte 236 et d’une variable sur laquelle porte . Chaque révision d’un arc a pour objectif d’éliminer les valeurs de sans support dans . AC3 nécessite la gestion d’un ensemble mémorisant les révisions restant à effectuer. En théorie, correspond à un ensemble d’arcs [Mackworth, 1977]. Toutefois, il est également possible de le considérer en tant qu’ensemble de variables [Chmeiss et Jegou, 1998; Bessiere et Regin, 2001; Zhang et Yap, 2001] ou en tant qu’ensemble de contraintes. Nous présentons ici ces trois alternatives dans le cas général de problèmes non binaires. 3.1 AC3 orienté-arc Nous commençons par décrire la variante AC3 orienté-arc qui est la plus simple et la plus naturelle. L’algorithme 1 en donne une description. Initialement, tous les arcs sont placés dans l’ensemble . Ensuite, chaque arc est révisé à tour de rôle, et lorsqu’une révision est efest effectuée. fective (au moins une valeur a été éliminée), une mise à jour de l’ensemble Un appel à la fonction # % , décrite par l’algorithme 2, permet d’éliminer les valeurs de inconsistantes (sans support) avec . Cette fonction retourne le nombre de valeurs éliminées. La fonction %! ! consiste à déterminer la présence ou l’absence d’un support de dans . En fonction du codage de cette fonction, on obtient les différents algorithmes de la famille de AC3. L’algorithme se termine lorsque l’ensemble devient vide. Algorithme 1 AC3 orienté-arc 1: !#"#$# %'& 2: while )*, ( + do 3: pick - in .0/21354768!:9;$<"3=#>?$53# @'A 4: 5: if .0/21B3=4 65:!9;$DCFE then 6: if G#684H ;A *+ then return FAILURE 7: else IFJ K'' KL8 !#"#$# K@M7KN7!"#$ @K@MOP* ( 8: end if 9: end while KQ R* ( K& 10: return SUCCESS Algorithme 2 revise(in C : Constraint, in X : Variable) : int 1: .M/21B3=4 68!9L$PE 2: for each !OG#684H ;A do 3: if $53835SUTWV:X#XY68"[Z\ @ !] *^ !:9;$53 then 4: remove ! from G654_ ;A .0/21354768!:9;$<.0/21354768!:9;$a`cb 5: 6: end if 7: end for 8: return .0/21B3=4 65:!9;$ 3.2 AC3 orienté-variable La seconde variante présentée ici, AC3 utilisant une gestion orientée variable, correspond à un principe utilisé par l’algorithme AC8 [Chmeiss et Jegou, 1998]. L’idée est de placer dans l’ensemble toutes les variables dont le domaine a été modifié. Initialement, toutes les variables sont placées dans l’ensemble . Puis, de façon itérative, chaque variable de est sélectionnée 237 et chaque contrainte portant sur est considérée. Il est alors possible d’effectuer des révisions sur cette base, c’est à dire la révision de tous les arcs avec . Lorsque la révision d’un arc entraı̂ne l’élimination de valeurs de $ , la variable est ajoutée (si elle n’est pas déjà présente) à l’ensemble . La lecture de l’algorithme 3 diffère quelque peu du principe énoncé ci-dessus. En effet, pour éviter des traitements inutiles, il est nécessaire d’utiliser un ensemble de compteurs (ou une structure de données équivalente) afin de déterminer si une révision donnée est indispensable ou non. Par exemple, prenons le cas d’une contrainte binaire portant sur les variables et . Si la sélection de la variable entraı̂ne une révision effective de (c’est à dire l’élimination d’au moins une valeur du domaine de ), puis la sélection de entraı̂ne une révision effective de , il est alors inutile de procéder de nouveau à la révision de si est de nouveau sélectionné et si le domaine de n’a pas été modifié par ailleurs. Comme autre exemple [Bessiere et Regin, 2001], prenons le cas d’une contrainte ternaire . Si la sélection de la variable entraı̂ne une révision de et de alors il est inutile de procéder à la révision de si la variable est sélectionnée et si les domaines de ou de n’ont pas été modifiés par ailleurs. En associant un compteur à chaque arc, il est possible de déterminer quelles sont les révisions intéressantes. La valeur de indique le nombre de valeurs éliminées du domaine de la variable depuis la dernière révision portant sur la contrainte . Initialement, de façon arbitraire, on positionne cette valeur à 1 pour tous les compteurs. Puis, lorsqu’une variable est sélectionnée et qu’une contrainte portant sur est considérée, on se trouve devant deux situations possibles. La première correspond à un schéma classique : est la seule variable que . Dans ce cas, on procède à la révision de tous les arcs de #$&% telle avec . Dans le cas contraire (seconde situation), tous les arcs , y compris , sont révisés. Il est en effet intéressant de réviser puisqu’au moins une pour autre variable de a été modifiée récemment. C’est la fonction c % # % , décrite par l’algorithme 4 qui permet de déterminer si la révision d’un arc est intéressante ou non. En considérant cette seconde situation et le fait que tous les compteurs associés à la contrainte sont réinitialisés à zéro après sa prise en compte, le test de la ligne 6 devient compréhensible : il permet d’éviter des traitements inutiles. 3.3 AC3 orienté-contrainte La troisième variante (originale à notre connaissance), AC3 utilisant une gestion orientée contrainte, consiste à placer dans l’ensemble toutes les contraintes pour lesquelles au moins une révision est nécessaire. Initialement, toutes les contraintes sont placées dans l’ensemble . est sélectionnée et chaque variable de Puis, de façon itérative, chaque contrainte de #$&% est considérée. Comme pour la variante précédente, une gestion de compteurs permet d’éviter des traitements inutiles. 3.4 MAC3 Les différentes variantes de l’algorithme AC3 ont été présentées ci-dessus dans un contexte général. Elles peuvent être appliquées directement à un problème sans tenir compte de l’emploi éventuel d’un algorithme de recherche. Or, il apparaı̂t que l’un des algorithmes complets de recherche les plus performants est l’algorithme qui maintient la consistance d’arc au cours de la recherche d’une solution [Sabin et freuder, 1994; Bessiere et Regin, 1996]. 238 Algorithme 3 AC3 orienté-variable 1: 5<8 & 2: M !#"#$# % ?XYZ\ b 3: while )*, ( + do 4: pick in 5: for each 8 !#"#$# % do 6: if ?XUZ\ 'A * E then continue 7: for each R7!"$# % do 8: if 4VM$2Z 768Z %381B35#>?$=38GQ then continue .0/21B3=4 65:!9;$%<"35#>?$=3 9: 10: if .M/21B354768!9L$DC E then 11: if G#684H *+ then return FAILURE 12: IFJ & 13: for each K 7) K * ( F !#"#$# K do ?XUZ\ @ 14: end if 15: end for 16: for each R7!"$# % do ?XUZ\ E 17: end for 18: end while K N?XUZ\ @ K M` .M/21B3=4 68!9L$ 19: return SUCCESS Algorithme 4 mustNotBeRevised(in C : Constraint, in X : Variable) : boolean 1: return ( ?XUZ\ 'A C E and )!"$# %B * ( )-XUZ\ CFE ) Une première modification à apporter aux algorithmes précédents consiste à ne prendre en compte que des révisions portant sur des variables futures, i.e., des variables qui ne sont pas assignées. Une seconde modification concerne l’initialisation à effectuer après l’assignation d’une valeur à une variable qui est appelée la variable courante. Pour la variante orienté-arc, il suffit de remplacer la ligne 1 de l’algorithme 1 par la suivante : #$&% où X désigne la variable courante Pour la variante orienté-variable, il suffit de remplacer les lignes 1 et 2 de l’algorithme 3 par les suivantes : où X désigne la variable courante #$&% #$&% où X désigne la variable courante. Pour la variante orienté-contrainte, il suffit de remplacer les lignes 1 et 2 de l’algorithme 5 par les suivantes : #$&% où X désigne la variable courante #$&% #$&% où X désigne la variable courante. 4 Heuristiques de choix pour la propagation A ce stade, il est naturel de s’interroger quant à l’intérêt réel des variantes orienté-variable et orienté-contrainte de AC3. En effet, même si les trois variantes apparaissent fondamentalement équivalentes, la variante orienté-arc est plus simple et plus naturelle (il n’est pas nécessaire de gérer des compteurs ou toute autre structure équivalente). Il existe pourtant une différence importante entre les trois variantes : la gestion de l’ensemble . En effet, la gestion d’arcs, de variables 239 Algorithme 5 AC3 orienté-contrainte 1: [ # & 2: M !#"#$# % ?XYZ\ b 3: while )*, ( + do 4: pick in !#"#$# % do 5: for each 6: if 4V $=Z 68Z %3[1B3=#>?$535GU then continue 7: .0/21354768!:9;$<"3=>@$53 8: if .M/21B3=4 68!9L$ C E then 9: if G#684H *+ then return FAILURE 7!"#$ @K@ do 10: for each KW )K * ( F IFJ [ K & 11: 12: ?XUZ\ K N ?XUZ\ @ K M` .M/21B3=4 68!9L$ 13: end for 14: end if 15: end for 16: for each !#"#$# % do ?XYZ\ DNIE 17: end while 18: return SUCCESS ou de contraintes a des répercussions sur le comportement de l’algorithme. A un certain niveau, le grain des variantes orienté-variable et orienté-contrainte est en effet plus gros que celui de la variante orienté-arc. Au lieu d’être un handicap, cela peut constituer un avantage. C’est ce que nous allons montrer en introduisant les heuristiques de choix de révisions, i.e., les heuristiques qui déterminent l’ordre dans lequel les révisions sont effectuées par AC3 (ou ses extensions). En effet, les différentes variantes de AC3 présentées dans la section précédente nécessitent toutes, au cours de la propagation, la sélection d’éléments de l’ensemble . Nous présentons ici les heuristiques qui nous ont parues les plus pertinentes, certaines sont issues ou sont des adaptations de travaux précédents (une discussion concernant ces travaux est proposée plus loin), d’autres sont originales. Nous commençons par l’heuristique qui peut être définie sans ambiguı̈té quelque soit la variante employée. Cette heuristique qui consiste à sélectionner l’élément le plus ancien de (géré comme une queue) est couramment employée dans la plupart des solveurs. Intuitivement, elle correspond au choix de l’élément dont le domaine a le plus de chances d’avoir été réduit. Par ailleurs, nous allons utiliser des heuristiques composées que nous représentons à l’aide se comporte comme suit : l’heuristique est du symbole . Une heuristique composée est prise en compte pour casser les noeuds sachant considérée, et, si nécessaire, l’heuristique qu’un noeud est un ensemble d’éléments considérés comme équivalents par une heuristique. Pour toutes les heuristiques, qu’elles soient élémentaires ou composées, lorsqu’un noeud doit être cassé, l’élément le plus ancien est choisi (autrement dit, est implicitement utilisé en dernier recours). 4.1 Heuristiques orienté-variables Chacune des heuristiques orienté-variables, i.e., adaptées à la variante orienté-variable, consiste à sélectionner une variable de l’ensemble ayant : : le plus petit domaine, – $ – $ : le plus grand degré, : la plus grande proportion de valeurs éliminées, – : le plus petit rapport ! où représente la taille du domaine de la variable – $ ! 240 et la proportion de valeurs éliminées. et sont complémentaires d’une certaine manière. La première Les heuristiques s’intéresse au nombre de valeurs restant dans le domaine tandis que la seconde s’intéresse à la proportion de valeurs supprimées récemment, c’est à dire depuis la dernière sélection de la permet de combiner ces deux points de vue. variable en question. L’heuristique $ ! Pour finir, remarquons que considérer un nombre brut de valeurs éliminées favorise plutôt la sélection de variables avec de grands domaines, ce qui entraı̂ne en règle générale un accroissement du nombre de tests de consistance. C’est pourquoi, nous avons préféré utiliser des proportions. 4.2 Heuristiques orienté-contraintes Chacune des heuristiques orienté-contraintes, i.e., adaptées à la variante orienté-contrainte, consiste à sélectionner une contrainte de l’ensemble ayant : : le plus petit domaine, – $ : la plus grande proportion de valeurs éliminées, – – $ ! : le plus petit rapport où représente la taille du domaine de la contrainte et la proportion de valeurs éliminées. et . Rappelons Les heuristiques et ! sont comparables aux heuristiques $ que nous appelons domaine (courant) d’une contrainte le produit cartésien des domaines (courants) associés aux variables de la contrainte. Le domaine ne doit pas être confondu avec la taille (ou satisfiabilité) de la contrainte définie par [Wallace et Freuder, 1992] comme représentant le nombre de supports courants de celle-ci. Les valeurs éliminées du domaine d’une contrainte correspondent aux tuples disparus du fait de la réduction du domaine de certaines variables. Par exemple, imaginons une contrainte binaire portant sur deux variables et . Si lors de la sélection précédente de , les domaines de et comportaient valeurs et que lors de la sélection courante ils n’en comportent respectivement que et , alors la taille du domaine courant de est égale à et la proportion de valeurs perdues est égale à . 4.3 Heuristiques AC3 orienté-arcs Chacune des heuristiques orienté-arcs, i.e., adaptées à la variante orienté-arc, consiste à sélectionner un arc de l’ensemble ayant : : la contrainte dont le domaine est le plus petit, – $ : la variable dont le domaine est le plus petit, – $ – $ : la variable dont le degré est le plus élevé, : le plus petit rapport entre la taille du domaine de la contrainte et la taille du – $ $ domaine de la variable. Notons que nous n’avons pas introduit d’heuristiques basées sur la notion de valeurs perdues par arc car leur mise en place nécessite une gestion de compteurs notablement plus complexe (et donc pénalisante en temps de calcul) que celle des variantes précédentes. 5 Travaux connexes Nous présentons ici quelques travaux connexes aux nôtres. Citons pour commencer les heuristiques proposées par [Wallace et Freuder, 1992] qui ont été développées dans le cadre de l’uti- 241 lisation de la variante AC3 orienté-arc en phase de pré-traitement pour des problèmes binaires. Ces heuristiques sont basées sur les trois critères principaux suivants : – le nombre de supports dans chaque contrainte, – le nombre de valeurs dans chaque domaine, – le degré de chaque variable. L’heuristique % , basée sur l’utilisation du premier critère, permet d’obtenir des résultats satisfaisants en terme de tests de consistance. Toutefois, déterminer le nombre de supports dans chaque contrainte et maintenir cette information n’est pas une approche très réaliste. Cette constatation est effectuée par [Gent et al., 1997] qui propose une heuristique , sur la base du nombre de supports dans chaque contrainte, permettant de minimiser la “constrainedness” du problème résultant après révision. Des expérimentations [Gent et al., 1997] montrent que , qui est coûteuse en temps de calcul, effectue moins de tests de consistance que % et à la phase de transition de la consistance d’arc. , basée sur l’utilisation du second critère, consiste à sélectionner l’arc L’heuristique $ tel que la variable , i.e. la variable contre laquelle la révision s’effectue, possède le plus petit domaine. Par rapport à notre notation et pour des problèmes binaires, cette heuristique correspond donc à $ . Si l’on considère la variante orienté-variable, alors on peut considérer que $ correspond également à . L’heuristique , qui correspond à $ , s’avère particulièrement décevante au niveau des expérimentations de [Wallace et Freuder, 1992]. Nous avons constaté le même phénomène au niveau de nos propres expérimentations. D’autre part, [Régin, 1995] évoque le problème de l’ordonnancement des valeurs éliminées en gérant une liste d’attente par variable. Cette approche reste, néanmoins, spécifique des algorithmes à grain fin. De leur coté, [Laburthe et le projet OCRE, 2000] proposent une approche originale en gérant la propagation en terme d’évènements associés aux variables et stockés dans des files ou des piles. Chaque événement déclenche la propagation immédiate de certaines contraintes liant la variable attachée à cet événement. Plus généralement, une architecture de propagation en couches permet la propagation des contraintes en fonction d’un compromis entre l’apport d’information et le temps de calcul. Pour finir, citons le travail de [van Dongen, 2002] qui souligne l’importance d’utiliser une heuristique de choix de révision et qui propose des heuristiques pour choisir l’ordre des tests de consistance effectués par chaque révision. Dans [van Dongen, 2003], une heuristique de choix de révision précise est présentée comme étant particulièrement adaptée à (une variante orienté-arc de la famille de AC3). Il s’agit d’une heuristique composée de critères élémentaires. $ . Si on ne considère que les premiers critères, elle correspond à $ 6 Expérimentations Pour prouver l’intérêt pratique de l’utilisation des heuristiques de choix d’éléments pour la révision, nous avons effectué une série d’expérimentations sur des problèmes aléatoires, réels et académiques. Pour cela, nous avons implémenté ces problèmes, ces heuristiques et l’algorithme AC2001/AC3.12 en Java sur la plate-forme Abscon [Merchez et al., 2001] et réalisé les tests sur un PC Pentium IV 2.4GHz sous Linux. Dans chacune de nos expérimentations, nous avons mesuré : le temps CPU (cpu), le nombre de tests de consistance (#ccks) et le nombre de sélections (#rohs) d’un élément de l’ensemble réalisées par l’heuristique de révision. 2 Nous n’avons pas utilisé l’algorithme AC3.2 car sa présentation est en cours de soumission. 242 variante variable variable variable variable variable variable contrainte arc arc arc arc contrainte arc contrainte contrainte arc arc G654 G#3 G654 "3=4 G654 G3 "354 ^ >^ 6 ^ >^ 6 ^ >^ 6 G#684 G#3 G#684 G#3 G654 G#684 G#684 "354 G654 "3=4 G#684 G#684 G#684 G#684 heuristique cpu E E E E #E E Qb E E E E E E E E E :b E E E b E P3 #ccks Q5bE ] E]b : E ]b] ] b ] # EE ] ] : b=E ] =b Q \E]b ] ] ] E ] : ] Q b ] ]bb #rohs [ E [ E [ E ]# E ] 'E ] E ] ] ] ] ] Q b ] ] 2b : cpu E E E E ]b E :b E ]b E E b b b b E b b EE b ]b E P4 #ccks b\E]E]b b\E ]b b\E ]E]b bE : ]b b\E ] [E bE : ]b b=bb ] b=b Q :b b\E E] b=b Q :b b\E E] ] :bb b\EE ]E b\E E]E ] : b\E ] E #rohs E b E : b ] b]=b b] b] =b b] E bQ ] 'E b] bQ b] TAB . 1 – Application de la consistance d’arc : instances aléatoires 6.1 Appliquer la consistance d’arc Nous considérons ici l’application de la consistance d’arc (sans recherche) sur deux problèmes distincts. La première série d’expérimentations concerne les problèmes aléatoires. Dans ce papier, une classe d’instances aléatoires est caractérisée par un 5-uplet où représente le nombre de variables, la taille uniforme des domaines, le nombre de contraintes d’arité et le nombre de tuples non autorisés pour chaque contrainte. Nous présentons tout d’abord les résultats de problèmes aléatoires étudiés par [Bessiere et al., 1999; Bessiere et Regin, 2001; Zhang et Yap, 2001]. Nous avons évalué (voir le tableau 1) le comportement des différentes de heuristiques par rapport aux classes P3= et P4= problèmes qui se situent à la phase de transition pour la consistance d’arc. P3 caractérise une classe de problèmes peu denses ( " ! ) et P4 une classe de problèmes denses ( #! ). Pour chaque classe, nous avons généré 50 instances et calculé la moyenne pour chacun des trois critères présentés précédemment. On peut immédiatement remarquer que le nombre de sélections (#rohs) est beaucoup moins important lorsqu’on utilise une heuristique orienté-variable. En fait, la sélection d’une variable entraı̂ne un nombre de révisions proportionnel à son degré tandis que, pour les heuristiques orienté-arcs, la sélection d’un arc n’entraı̂ne qu’une seule révision, et pour les heuristiques orienté-contraintes, la sélection d’une contrainte d’arité entraı̂ne au plus révisions. La variante orienté-variable présente donc clairement un grain plus gros : le nombre de tests de consistances effectués après chaque sélection est de à fois plus important. Nous pouvons également observer que la variante orienté-variable est la plus rapide, notamment lorsqu’elle est associée à une heuristique de choix basée sur . Ce comportement peut s’expliquer de la manière suivante : la variante orienté-variable entraı̂ne moins de sélections, comme indiqué plus haut, et chaque sélection est moins coûteuse. En effet, le coût d’une sélection est, en règle générale, moins important car le nombre de variables est plus faible que le nombre de contraintes et, à fortiori, d’arcs. En terme de tests de consistance, les meilleures heuristiques sont celles de la variante orienté tandis que les plus mauvaises sont les heuristiques contrainte basées sur l’heuristique $ 243 variante variable variable variable variable variable variable contrainte arc arc arc arc contrainte arc contrainte arc contrainte arc heuristique G#684 G#684 "354 G#684 G#3 "[354 G#3 ^ >^ 6 ^ >^ 6 ^ >^ 6 G#684 G#684 G#3 G#3 G#684 G#684 G#684 "[354 G#684 G#684 G#684 "354 G#684 G#684 cpu E bb E bb E b E b E E E E E ]b b Q bb ] b [ E b=E E b=E SCEN#05 #ccks ]E ] ] Q E :b] 5b bE]bQ Q b bE] \E]b b\EQ E] ] b ] E] ] ] : b ] [ E ] E E] =b ] E #rohs ] b ]b [ E b=b b ]EEE b][ E]b E]] b b] E E] ] \E]b=E b] : \E ] ] b] E cpu E E E E E E E E E b E ]b E E ]b ]b b ] b SCEN#08 #ccks ] ] E ] E ] =b=E E][ E ] E ]2b: ]: ] : b ] E : ] Q ] ] b : E ] =bb #rohs b ]b ]E b: E# E ] E ] ] ] b ] ] b b TAB . 2 – Application de la consistance d’arc : instances RLFAP (toutes variantes confondues). Remarquons toutefois que le temps d’exécution de ces dernières demeure acceptable, le coût d’une sélection étant négligeable. Nous avons également comparé les différentes heuristiques sur les instances réelles notées SCEN#05 et SCEN#08 de l’archive RLFAP3 . Les résultats présentés sur le tableau 2 confirment les remarques précédentes. Notons l’écart important entre les heuristiques et les autres en termes de tests de consistance pour l’instance SCEN#08. On retrouve, pour cette instance, des mesures similaires à celles observées par [van Dongen, 2002] à l’aide de l’algorithme AC3 . 6.2 Maintenir la consistance d’arc Pour réaliser nos expérimentations, nous avons implémenté une version de MAC2001/3.1 qui intègre l’heuristique de choix de variable $ $ et l’heuristique de choix de valeur . En premier lieu, nous avons étudié le comportement de l’algorithme MAC sur des instances aléatoires uniformes (les noeuds des graphes de contrainte et d’incompatibilité ont tous le même degré) générées à partir des classes Q1= de problèmes binaires denses ( %) et Q2= de problèmes ternaires peu denses ( %). Les instances générées se situent à la phase de transition pour la recherche et vérifient le théorème 2 de [Xu et Li, 2000], ce qui assure qu’elles soient difficiles. Les résultats correspondent à une moyenne sur 50 instances (dont 21 sont satisfiables pour Q1 et 14 pour Q2) et sont présentés sur le tableau 3. On peut distinguer trois groupes d’heuristiques. Le premier groupe comprend essentiellement les heuristiques orienté-arcs et orienté-contraintes qui sont basées sur la notion de plus petit domaine. Elles sont les plus efficaces en terme de tests de consistance, mais restent médiocres en temps cpu. Le deuxième groupe est constitué d’heuristiques orienté-variables basées également sur la notion de plus petit domaine. Ces heuristiques bien que moyennes en terme de tests de consistance se révèlent les plus efficaces en temps cpu. Enfin, remarquons que les heuristiques se situent, une fois de plus, dans le groupe constitué des heuristiques les moins efficaces en nombre de tests de consistance. 3 Nous remercions le Centre d’Electronique de l’Armement. 244 G#684 G654 G#684 G#684 "354 G#684 G654 G#684 G#684 G#68 4 G#684 G3 G#68 4 G3 G#68 4 G#684 "354 "3=4 "3= 4 G#3 G#3 ^ >^ 6 ^ >^ 6 ^ >^ 6 variante arc contrainte contrainte arc arc arc arc variable variable variable variable contrainte arc variable arc variable contrainte heuristique cpu E b] b E b b=E b ]b b b=E]b b=EE Q1 #ccks E M b M E M M b=E M E M E ]b M M M b M [E EEE M :b :b M ]b M b=E M M ]b M [E M #rohs b M bb E M b=E ]b M b E M M b b M b Qb M b E M b E M b E M b b M b E M M b ]b M ]b bb M b M b E E M cpu b E b ]b=E b b E b=E EE b] b b b b] b b Q2 #ccks b=E M bbb Qb M bbb M b [E M b=E Qb M b E Qb M b M b E M b M b M M b b M b ]b M E]b E ]b M E ]b M E :b M ]b=E M #rohs Qb M b ] b M b M E M ]b M M b M M M M bb M b E]b M M M M M ]b M TAB . 3 – Maintien de la consistance d’arc : instances aléatoires uniformes En deuxième lieu, nous nous sommes intéressés à un problème académique, appelé Golomb Ruler, défini sur le serveur CSPLib4 . Ce problème consiste à placer marques sur une règle de longueur tel que les distances entre deux marques soient toutes différentes. Nous donnons sur le tableau 4 les résultats obtenus pour = qui correspond au nombre maximum de marques possibles sur une règle de longueur et pour = qui n’a donc pas de solution. Ce problème comprend à la fois des contraintes binaires et ternaires. Pour finir, nous avons étudié le comportement des heuristiques vis à vis de 2 instances réelles, notées et de l’archive RLFAP. Les résultats de ces deux dernières expérimentations (voir les tableaux 4 et 5) mettent en évidence l’efficacité des heuristiques orienté-variables en terme de temps. De manière générale, nous pouvons dire que l’efficacité (en temps CPU) des heuristiques a été établie que ce soit lors de l’application de la consistance orienté-variables basées sur $ d’arc ou lors de la recherche d’une solution. D’autre part, nous avons relevé que les heuristiques orienté-arcs et orienté-contraintes qui permettent de sauver des tests de consistance s’avèrent plus coûteuses. Dans tous les cas de figure, pour améliorer la performance des différentes heuristiques, trois pistes nous semblent envisageables : – limiter la recherche du meilleur élément à un sous ensemble de , – effectuer la recherche des meilleurs éléments une fois sur , – améliorer la gestion de l’ensemble (e.g., en utilisant un tri par casier comme dans [Wallace et Freuder, 1992]). 7 Conclusion Dans ce papier, nous avons cherché à éclaircir la situation concernant l’utilisation des algorithmes de la famille de AC3. En effet, il apparaı̂t que trois variantes de cet algorithme peuvent être définies : les variantes orienté-variable, orienté-contrainte et oriente-arc. Nous nous sommes 4 http ://4c.ucc.ie/ tw/csplib/ 245 variante variable variable variable variable variable variable contrainte arc arc contrainte arc arc arc contrainte arc arc contrainte G#684 G#3 G#684 G#684 "3=4 "354 ^ >^ 6 G#3 ^ >^ 6 ^ >^ 6 G654 G#684 G654 G#3 G654 G#684 G654 G#684 G#684 "3=4 G3 G654 #G 684 "354 9 * heuristique cpu E E E] b ] b b=E]b b ] b ] b E b E E b 4 * #ccks Qb M M EE M b M M b M M b=E M E M M E M M M M b M E E M #E M 9 * #rohs b] b]E ]b b] b] ]b ] E] ]EE E] ]b Qb E ] E ] ] : ] ]b E ]=b ]b ] E cpu b=E b=E E b=E E b b=E bE E]b b b b b b E : b ]b E ] b b bb# E ] b 4 * ]b M ]b E M ]b E M b] b M : b M E M ]b E M E Q b M b E[ E M ] b E]b M b E M b M ] b ] b M ] b E M E M [ E M E M #ccks #rohs M E M E M E :b M E M b E M M b M b #E M M b b M b M E ]b M b :b M E M M b ]b M E TAB . 4 – Maintien de la consistance d’arc : instances “Golomb ruler” attachés à décrire ces variantes afin qu’elles puissent être utilisées pour des problèmes d’arité quelconque tout en mettant en place un mécanisme (pour les variantes orienté-variable et orientécontrainte) permettant d’éviter les révisions inutiles. Les études menées par [Wallace et Freuder, 1992; Gent et al., 1997] ont montré que l’ordre des révisions effectuées par un algorithme tel que AC3 avait une répercussion significative sur l’efficacité de l’algorithme. Un certain nombre d’heuristiques, trois principalement, ont été proposées par [Wallace et Freuder, 1992] et expérimentées dans le contexte de l’utilisation de la variante orienté-arc de AC3 avant une recherche de solution pour des problèmes binaires (dont la taille est limitée). Dans ce papier, nous avons prolongé cette étude : – en introduisant de nouvelles heuristiques et en adaptant celles définies par [Wallace et Freuder, 1992] aux différentes variantes de l’algorithme AC3, – en expérimentant ces heuristiques avant et/ou pendant la recherche d’une solution pour des problèmes binaires et non binaires. La lecture des résultats expérimentaux montre que les meilleures heuristiques consistent à sélectionner les éléments (variable, contrainte ou arc) sur la base de la taille de leurs domaines. Les meilleures heuristiques permettent de sauver jusqu’à #! de tests de consistance par rapport à l’heuristique standard . Ainsi, cela confirme pour MAC l’observation effectuée par [Wallace et Freuder, 1992]. Par ailleurs, les meilleures heuristiques orienté-variables permettent ! de temps CPU par rapport à tandis que les heuristiques orientéde gagner environ " contraintes et orienté-arcs sont pénalisées en terme de temps de calcul du fait de la longueur, généralement plus importante, des listes à parcourir. Même si plusieurs pistes existent afin d’optimiser les différentes heuristiques, nous sommes convaincus que le bon comportement général devrait lui préserver un avantage. d’une heuristique orienté-variable telle que Remerciements Ce travail a été soutenu, en partie, par l’IUT de Lens, le CNRS et la région Nord-Pas de calais dans le cadre du programme TACT. 246 variante variable variable variable variable variable arc variable arc contrainte arc arc contrainte arc contrainte arc contrainte arc G#684 "354 G#684 G3 G#684 "3=4 G#3 G#68 4 ^ >^ 6 ^ >^ 6 ^ >^ 6 G#684 G3 G#3 G#684 G#684 G654 G#684 "354 G#684 G654 "3=4 G#684 G#684 heuristique cpu b ] b b=EE ] b b=E b=E E b=E ] b b=E bb=E bb E bb b] b ] b b# E b b b ]bb E SCEN#11 #ccks M ]b M M M E E M E M EE M E M M M E M M M M [E]b M E M M #rohs E M ]b=E M E M ]b=E M M ]b M [E M M M ]b M M M E M M E]b M M M E E E E E E cpu b b ]b b b b E b b ]b b E b=E b ] b b b GRAPH#14 #ccks b M b M b M M b M b b ]b=E M b ]b M b ]b M b ]b M b E M b ]b M b M b M M b M b b M b E M #rohs Q Q Q Q Q[ E ] [ E ] [ EE ] E]\E E ] ] \E] b Q E ] E ] ] =b ] E E]] b TAB . 5 – Maintien de la consistance d’arc : instances RLFAP Références [Bessiere et al., 1999] C. Bessiere, E.C. Freuder, et J. Regin. Using constraint metaknowledge to reduce arc consistency computation. Artificial Intelligence, 107 :125–148, 1999. [Bessiere et Regin, 1996] C. Bessiere et J. Regin. MAC and combined heuristics : two reasons to forsake FC (and CBJ ?) on hard problems. Dans Proceedings of CP’96, pages 61–75, Cambridge MA, 1996. [Bessiere et Regin, 2001] C. Bessiere et J. Regin. Refining the basic constraint propagation algorithm. Dans Proceedings of IJCAI’01, pages 309–315, 2001. [Bessiere, 1994] C. Bessiere. Arc consistency and arc consistency again. Artificial Intelligence, 65 :179–190, 1994. [Chmeiss et Jegou, 1998] A. Chmeiss et P. Jegou. Efficient path-consistency propagation. International Journal on Artificial Intelligence Tools, 7(2) :121–142, 1998. [Gent et al., 1997] I.P. Gent, E. MacIntyre, P. Prosser, P. Shaw, et T. Walsh. The constraindedness of arc consistency. Dans Proceedings of CP’97, pages 327–340, 1997. [Laburthe et le projet OCRE, 2000] F. Laburthe et le projet OCRE. CHOCO : implémentation du noyau d’un système de contraintes. Dans Actes de JNPC’00, pages 151–165, 2000. [Lecoutre et al., 2003] C. Lecoutre, F. Boussemart, et F. Hemery. De AC3 à AC7. Dans Actes de JFPLC’03, 2003. [Mackworth, 1977] A. K. Mackworth. Consistency in networks of relations. Artificial Intelligence, 8(1) :118–126, 1977. [Merchez et al., 2001] S. Merchez, C. Lecoutre, et F. Boussemart. Abscon : a prototype to solve CSPs with abstraction. Dans Proceedings of CP’01, pages 730–744, 2001. [Mohr et Henderson, 1986] R. Mohr et T.C. Henderson. Arc and path consistency revisited. Artificial Intelligence, 28 :225–233, 1986. [Régin, 1995] J.C. Régin. Développement d’outils algorithmiques pour l’intelligance artificielle. Application à la chimie organique. PhD thesis, Université Montpellier II, 1995. 247 [Sabin et freuder, 1994] D. Sabin et E. freuder. Contradicting conventional wisdom in constraint satisfaction. Dans Proceedings of the PPCPA’94, Seattle WA, 1994. [van Dongen, 2002] M.R.C. van Dongen. AC3 an efficient arc consistency algorithm with a low space complexity. Dans Proceedings of CP’02, pages 755–760, 2002. [van Dongen, 2003] M.R.C. van Dongen. Lightweight arc-consistency algorithms. Technical Report TR-01-2003, University college Cork, 2003. [Wallace et Freuder, 1992] R.J. Wallace et E.C. Freuder. Ordering heuristics for arc consistency algorithms. Dans Proceedings of NCCAI’92, pages 163–169, 1992. [Wallace, 1993] R.J. Wallace. Why AC3 is almost always better than AC4 for establishing arc consistency in CSPs. Dans Proceedings of IJCAI’93, pages 239–245, 1993. [Xu et Li, 2000] K. Xu et W. Li. Exact phase transitions in random constraint satisfaction problems. Journal of Artificial Intelligence Research, 12 :93–103, 2000. [Zhang et Yap, 2001] Y. Zhang et R.H.C. Yap. Making AC3 an optimal algorithm. Dans Proceedings of IJCAI’01, pages 316–321, Seattle WA, 2001.