Dans cette section, nous nous concentrons sur la dimension théorique de l’heuristique CDCSolver et en exposons les mécanismes au travers des notions génériques de contraintes de design et contraintes de conflit, indépendamment des opérateurs définis en supra.
Nous avons détaillé, au chapitre 6, deux méthodes récentes de recherche locale pour la résolution de problèmes de satisfaction de contraintes : la recherche adaptative et l’heuris-tique CN -tabou. La première manipule des configurations totalement instanciées et utilise une « projection » des contraintes sur les variables pour choisir celle à modifier en priorité. La seconde garantit en permanence une consistance locale sur des instanciations partielles. Lorsqu’une nouvelle valeur est assignée à une variable libre, l’instancation est propagée en désaffectant les variables en conflit.
L’algorithme CDCSolver combine les deux méthodes. A partir d’une configuration incon-sistante, on commence par modifier ou désinstancier — en les remplaçant par l’élément neutre — les variables impliquées dans les contraintes de conflit. Lorsque ces dernières sont toutes vérifiées, une variable libre est alors instanciée de manière à réduire les contraintes de design. Les affectations se poursuivent soit jusqu’à la satisfaction de l’ensemble des contraintes, soit jusqu’à l’apparition de nouveaux conflits. Dans ce dernier cas, le processus précédent est répété tant qu’un nombre maximal d’itérations n’a pas été dépassé. A chaque mouvement, une heu-ristique permet de déterminer la variable à modifier en premier (dans le cas d’une contrainte de conflit) ou à instancier en priorité (dans le cas d’une contrainte de design). Contrairement à la recherche adaptative, il n’est pas possible de comptabiliser le nombre de contraintes violées dans lesquelles intervient chaque variable, en raison du caractère global de nos contraintes. Nous procédons alors de la manière suivante :
• Si une contrainte de conflit est violée dans la configuration courante K, alors nous calcu-lons la consistance pour toutes les configurations obtenues à partir de K en remplaçant tour à tour chaque variable instanciée par l’élément neutre. La configuration de coût minimal correspond alors à la variable à modifier en priorité (voir algorithme 5). • Si une contrainte de design est violée dans la configuration courante K, alors nous
10.3. CDCSOLVER 147
tour à tour chaque variable libre par une valeur aléatoire de son domaine. La confi-guration de coût minimal correspond alors à la variable à instancier en priorité (voir algorithme 6). Si aucune variable n’est libre, le choix s’effectue par désinstanciation, selon la méthode appliquée aux variables de conflit.
Dans les deux cas, la valeur de la variable modifiée est remplacée par toutes les autres du domaine, et la configuration de coût global minimal est retenue comme configuration courante.
Algorithme 5 Modification de la pire variable conflictuelle (change_worst_variable) Arguments: Une configuration initiale K = (x1, . . . , xN), une fonction de coût z.
1: pour i∈ {1, . . . , N} faire 2: si xi6= e alors 3: Ki← (x1, . . . , xi−1, e, xi+1, . . . , xN) 4: zi← z(Ki) 5: sinon 6: zi← ∞ 7: fin si 8: fin pour 9: i∗← argmin zi 10: pour xji∗ ∈ ¯Di∗\ {xi∗} faire 11: Kj ← (x1, . . . , xi∗−1, xji∗, xi∗+1, . . . , xN) 12: zj← z(Kj) 13: fin pour 14: j∗← argmin zj 15: retourner Kj∗
Cycles et minima locaux
Le fonctionnement de CDCSolver (voir algorithme 7) est donc basé sur une alternance de méthodes change_worst_variableetinstanciate_best_variable. Bien souvent, ces dernières ont des objectifs contradictoires : remplacer une variable affectée par l’élément neutre permet de soulager les contraintes de conflit, au risque de violer davantage de contraintes de design (et vice-versa). L’algorithme peut donc rapidement se retrouver enfermé dans un cycle dû à la présence d’un minimum local dans la fonction de coût (voir section 6.4.1). Pour éviter ce problème, CDCSolver dispose d’une mémoire à court terme de type « tabou ». Cette technique proposée par Glover [GL97] consiste à stocker dans une liste FIFO — dite « liste tabou » — les dernières configurations visitées. Lors de l’exploration du voisinage courant, le mouvement ne peut se faire vers une configuration de la liste tabou.
En pratique on se contente souvent, pour éviter d’avoir à rechercher une configuration passée dans une liste potentiellement longue, de « marquer tabou » la dernière variable modi-fiée ; on ne pourra alors pas changer cette variable tant qu’elle demeurera dans la liste tabou. CDCSolver utilise une version dynamique de ce principe : lorsqu’une variable est modifiée, elle est « marquée tabou » pour un nombre d’itérations égal au nombre de fois où la variable a déjà été modifiée depuis le début de l’exécution. Ce mécanisme, utilisé par Vasquez & Dupont [VHD03] dans l’heuristiqueCN -tabou, permet de s’adapter en cours d’exécution à la longueur des cycles engendrés par le paysage de la fonction de coût.
148 CHAPITRE 10. GESTION DES CONTRAINTES
Algorithme 6 Instanciation de la meilleure variable libre (instanciate_best_variable) Arguments: Une configuration initiale K = (x1, . . . , xN), une fonction de coût z.
1: pour i∈ {1, . . . , N} faire
2: si xi= ealors
3: xr
i ← une valeur aléatoire de Di 4: Ki← (x1, . . . , xi−1, xr i, xi+1, . . . , xN) 5: zi← z(Ki) 6: sinon 7: zi← ∞ 8: fin si 9: fin pour 10: si min zi=∞ alors 11: K∗← change_worst_variable(K) 12: retourner K∗ 13: sinon 14: i∗← argmin zi 15: pour xji∗ ∈ Di∗ faire 16: Kj← (x1, . . . , xi∗−1, xji∗, xi∗+1, . . . , xN) 17: zj ← z(Kj) 18: fin pour 19: j∗← argmin zj 20: retourner Kj∗ 21: fin si
Dans notre algorithme, seules les variables non tabou peuvent donc être modifiées. Cette restriction est forte, car elle interdit d’explorer de nombreuses configurations n’ayant pas encore été visitées. La technique habituellement utilisée pour contrecarrer cet effet est l’aspiration : si la modification d’une variable marquée « tabou » permet d’atteindre une valeur de coût infé-rieure à celle de la meilleure configuration obtenue jusqu’alors, le statut « tabou » est exception-nellement révoqué. En pratique, les méthodeschange_worst_variableetchange_best_variable
commencent par essayer de modifier une variable marquée « tabou ». Si l’aspiration n’est pas justifiée, le voisinage non « tabou » est alors exploré.
Pour des raisons de lisibilité, les opérations liées à la gestion des statuts « tabou » ne figurent pas dans les algorithmes 5, 6 et 7.
Complexité
Soient N le nombre de variables (i.e. le nombre d’instruments dans l’orchestre), d le nombre moyen de valeurs dans chaque domaine ¯Di et p le nombre de contraintes dans un problème d’orchestration. A chaque itération de CDCSolver, le calcul de la variable à modifier néces-site au plus N p opérations (procédures change_worst_variable ou change_best_variable et engendre un voisinage de d− 1 configurations sur lesquelles la consistance doit être calculée à chaque fois, soit (d− 1)p opérations. La complexité à chaque itération de CDCSolver est donc dans le pire cas enO((N + d − 1)p).
Dans l’algorithme de recherche adaptative, l’identification de la variable à modifier ne dépend que des valeurs des p contraintes calculées sur la configuration en cours, soit un calcul à chaque étape enO(dp). La complexité de CDCSolver est donc légèrement supérieure, mais
10.3. CDCSOLVER 149
Algorithme 7 Réparation des configurations inconsistantes (cdcsolver) Arguments: Une configuration initiale K, une fonction de coût z.
1: Kbest← K
2: iter← 1
3: tant que iter < itermax faire
4: tant queK viole au moins une contrainte faire
5: tant queK viole au moins une contrainte de conflit faire
6: K ← change_worst_variable(K)
7: si z(K) ≤ z(Kbest)alors
8: Kbest← K
9: fin si
10: iter + +
11: fin tant que
12: siK viole au moins une contrainte de design alors
13: K ← instanciate_best_variable(K) 14: si z(K) ≤ z(Kbest)alors 15: Kbest← K 16: fin si 17: iter + + 18: fin si
19: fin tant que
20: fin tant que
21: retourner Kbest
reste du même ordre de grandeur que la recherche adaptative, le paramètre N étant dans tous les cas majoré par la taille des plus gros orchestres.
Intégration de la fitness dans la fonction de coût
La fonction de coût z dans l’algorithme 7 est par défaut la somme des fonctions de coût as-sociées à chaque contrainte du réseau. A chaque mouvement, l’algorithme se déplace donc vers la configuration du voisinage courant qui viole le moins les contraintes. Si plusieurs choix sont possibles, la nouvelle configuration est choisie aléatoirement, sans se soucier de ses propriétés timbrales (i.e. de ses valeurs de descripteurs).
Dans un contexte d’optimisation multicritère, on pourrait très bien décider de choisir, au sein du voisinage courant de consistance maximale (i.e. de fonction de coût minimale), une solution non-dominée. Cela nécessiterait toutefois un grand nombre de comparaisons de valeurs à chaque mouvement. En revanche, il existe un cas de figure dans lequel les poids relatifs des critères intervenant dans les fonctions scalarisantes de Tchebycheff (voir sections 5.7 et 9.3) sont connus : lorsqu’après une première exécution de l’algorithme, le compositeur choisit une solution intermédiaire pour relancer la recherche (voir section 13.3) ou pour la transformer à l’aide de contraintes (voir sections 10.6 et 13.3), alors les poids ne sont plus aléatoires, mais déduits des valeurs de critères de cette solution (voir annexe B). La recherche devient alors mono-critère, guidée par une fonction scalarisante unique.
Nous avons dans ce cas tout intérêt à considérer, en plus de la consistance, la valeur de fitness pour guider les mouvements de CDCSolver. Lors de l’exploration du voisinage cou-rant, la nouvelle configuration sera celle de meilleure fitness parmi les configurations les plus
150 CHAPITRE 10. GESTION DES CONTRAINTES
consistantes (i.e. de coût minimal). Il suffit pour cela de modifier la fonction de coût z dans les méthodes change_worst_variable ou change_best_variable ainsi que dans l’algorithme principal : en rajoutant à z la valeur de fitness, on obtient une fonction de coût qui favo-rise les configurations les plus consistantes, tout en pénalisant, à niveau égal de violation de contraintes, les configurations de plus grande fitness (i.e. les moins adaptées).
Quand cela est possible, CDCSolver prend donc à sa charge une partie de l’optimisation. La recherche profite alors de la complémentarité entre les méthodes de recherche locale et les méthodes à population.