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.

Documents pareils