Stockage des nogoods

Les structures utilisées pour propager et retro-propager les décisions ayant été adaptées, nous avons remarqué que le contrôle de l’appartenance de la configuration partielle courante à la liste des nogoods stockés est désormais la procédure qui impacte le plus la rapidité de la méthode. Le Tableau 29 donne quelques grandeurs utiles pour montrer le temps de calcul imparti à la vérification des nogoods. Sans vérification de l’appartenance de la configuration partielle courante aux nogoods, le nombre d’itérations effectué en 5 secondes est 3 à 5 fois plus important. A noter qu’aucun des problèmes n’est résolu en 5 secondes.

Nom k T(s) ^Iter

Tabu-NG avec nogood

Iter

Tabu-NG sans nogood

le450_15c 15 5 72543 196547 le450_15d 15 5 67283 181848 le450_25c 25 5 57770 214568 le450_25d 25 5 57686 216493 le450_5a 4 5 46585 208671 le450_5b 4 5 46067 224291 le450_5c 4 5 46902 211455 le450_5d 4 5 43277 211857

Tableau 29 : Nombre d’itérations de Tabu-NG en 5 secondes avec et sans nogood

Nous avons complété ce test par une vérification du gain en qualité des solutions produites avec l’utilisation des nogoods afin de justifier la lenteur apportée. La méthode Tabu-NG étant déterministe la mesure de performances peut se faire sans erreur. Le Tableau 30 affiche le nombre d’itérations (ou de configurations) nécessaire pour obtenir la solution de 3 problèmes DIMACS avec les deux approches avec et sans stockage de nogoods. Les résultats montrent que l’impact de l’élimination du test d’appartenance des nogoods est réel mais faible sur le nombre de configurations visitées pour trouver une solution optimale au problème. Si le critère de comparaison d’algorithme est le nombre de configurations visitées alors le stockage des nogoods est justifié ; si le critère est le temps nécessaire pour trouver une solution alors on peut penser que, toute proportion gardée, l’écart entre le nombre d’itérations gagné avec le stockage pour trouver l’optimum et la lenteur supplémentaire engendré, ne justifie pas forcément leur utilisation. Le fait est que pour les problèmes difficiles, demandant éventuellement de visiter beaucoup de configurations, et pour les problèmes irréalisables, il vaut mieux privilégier la rapidité des calculs pour visiter plus de configurations dans le temps imparti.

Nom k Solution optimale trouvée

Iter

Tabu-NG avec nogood

Iter

Tabu-NG sans nogood

le450_5c 6 Oui 2103 2114

le450_5d 6 Oui 3732 3752

inithx.i.2 31 Oui 676 676

Nous avons analysé plus en détail l’apport des nogoods tels qu’utilisés pour le FAP dans le cadre de la coloration car ils contribuent beaucoup moins vite à trouver une solution en coloration. Le but principal de la propagation de contraintes est la prévention du blocage le plus tôt possible et par la suite d’éviter d’aller loin dans une branche non prometteuse de l’arbre de recherche. Le but principal des nogoods est de bénéficier des informations déjà trouvées pendant la recherche. Si l’ajout d’une certaine instanciation à la configuration partielle courante est reconnu comme cause de blocage (deadend) immédiat ou pas, il est important d’éviter à nouveau le choix de cette instanciation. La gestion des nogoods gagne en efficacité au fur et à mesure de la recherche permettant à la méthode de détecter les situations de blocage de plus en plus tôt et de fournir une protection contre le recours excessif aux procédures de propagation de contraintes.

Dans le cadre de la coloration, les phénomènes de symétrie ne sont pas gérés par le stockage actuel des nogoods, ces derniers sont donc moins efficaces pour détecter les coupes et réduisent moins efficacement l’espace de recherche que pour le FAP. Par ailleurs la nature des contraintes fait que l’on propage moins loin les affectations courantes rendant les coupes très basses dans l’arbre ou pourrait-on dire très locales par rapport à la dernière décision prise. Les nogoods actuels gèrent donc quelques cas de trashing pour la coloration mais très peu comparativement au FAP. Nous avons par conséquent tranché en faveur de l’élimination de la procédure de test d’appartenance aux nogoods pour gagner du temps en calcul. Un travail est à faire sur l’adaptation des nogoods stockés pour le cas de la coloration afin de placer des coupes plus générales qu’actuellement et donc plus efficace pour trouver les bonnes branches de l’arbre.

Dans l’immédiat nous avons décidé de supprimer la procédure de stockage des nogoods. Ainsi lors d’un deadend, le nogood responsable est calculé directement puis guide la procédure de désaffectation de variables pour rendre la configuration consistante ; aucune information n’est conservée par la suite. On garde donc une procédure d’explication locale mais l’apprentissage des poids sur l’ensemble des nogoods n’est pas conservé. Ainsi toutes les affectations indiquées dans le nogood seront directement annulées. Par exemple, en référence à la Figure 31, 4 nogoods seront identifiés et tous désaffectés, soient 5 variables libérées. A ce stade, toutes les variables qui étaient bloquées suite à la dernière instanciation se débloquent directement du fait de l’annulation de la dernière instanciation qui se trouve forcément dans le

nogood et qui va être annulée.

4.3. Méthode Tabu-NG pour la coloration de graphe

Nous donnons dans cette section, le pseudo code de notre méthode après les adaptations. Le schéma général de la méthode est donné dans la Figure 32, l’architecture reste la même. La méthode commence par une configuration partielle vide qu’elle modifie itérativement. A chaque itération, elle étend cette configuration en choisissant une nouvelle instanciation (variable, valeur). Après la phase d’extension, la méthode lance la procédure de propagation de contraintes. Après cette étape, deux cas peuvent se présentés :

1. Blocage : la méthode répare la configuration partielle en annulant une ou plusieurs instanciations déjà faites et revient à l’étape d’extension.

2. Pas de blocage : si la configuration est complète alors une solution valide est trouvée ; sinon on poursuit l’extension de la configuration partielle.

Le changement touche la forme plutôt que le fond de la méthode. Elle reste constructive et déterministe, elle se base toujours sur la liste de nogoods pour réparer la solution courante même si la notion de stockage des nogoods est supprimée. Suite à une réparation, la rétro-propagation annule directement le deadend (cf. section 4.2.4), par rapport à l’organigramme du chapitre 1, Figure 14, il n’y a donc plus la boucle sur le test de la persistance d’un deadend.

Figure 32 : Schéma général de Tabu-NG pour la coloration de graphe

Le pseudo code de la méthode Tabu-NG pour les problèmes de coloration de graphe est donné dans Algorithme 27.

Procedure Tabu-NG ()

1. S = vide

2. do

3. (x, v) = EtendreConfiguration(S);

4. isDeadEnd = PropagerAffectation(x, v) ;

5. while isDeadEnd == true do

6. S = ReparerConfiguration(S)

7. isDeadEnd = PropagerInverse()

8. endwhile

9. while(S est partielle)

Algorithme 27 : Pseudo-code général de Tabu-NG pour la coloration de graphe

Dans les sections suivantes, nous donnons les paramètres de la méthode. Dans un premier temps, nous avons conservées les mêmes paramètres testés sur les problèmes d’affectation de fréquences et les avons testés sur les problèmes de coloriage de graphe. Suite aux résultats obtenus, nous avons commencé à réfléchir à adapter ces paramètres en fonction du problème traité.