Renforcement du processus d’insertion

Contrairement à ce qui se passe ou sein d’une exploitation réelle, nous exigeons, dans notre modèle du DARP, l’intégration de toutes les demandes qui sont émises. Dans certains cas, notamment lorsque les contraintes de temps sont particulièrement serrées, il peut apparaître que certaines demandes n’ont pu être insérées au terme de la procédure d’insertion alors qu’il existe bien une solution où toutes peuvent l’être. Rappelons que le processus d’insertion comporte deux niveaux de décision : la sélection de la demande et le choix des paramètres pour l’insérer. C’est au travers de ces deux niveaux qu’est impacté le succès (ou l’échec) de l’insertion d’une demande. Nous allons voir comment les renforcer l’un et l’autre.

Apprentissage simple

Le premier niveau de décision de notre méthode concerne le choix de la demande à insérer. Il est réalisé selon le nombre de véhicules pouvant encore l’accepter. Cette information peut ne pas être suffisante.

On peut l’affiner en échangeant des informations entre les différentes réplications afin de repérer les différentes demandes qui ont du mal à s’intégrer aux tournées. Il est donc possible d’introduire une notion d’apprentissage dans l’algorithme IN- SERTIONAleatoire, c’est-à-dire au sein du processus de Monte-Carlo. Pour cela, on pondère les éléments de D au niveau de la procédure de sélection de la demande à insérer (E4). Au terme de chaque réplication, le processus repère les demandes rejetées et leur impose un poids fonction du nombre de fois où elles ont été exclues :

la priorité devient plus forte à chaque fois qu’il y a rejet. En effet, plus le poids de- vient élevé plus la demande peut-être considérée comme critique et difficile à insérer. Ainsi, le processus de sélection sélectionne en priorité les demandes au plus grand poids. Cet apprentissage permet donc de cibler les demandes qui sont difficiles à insérer afin de les sélectionner plus tôt dans le processus général.

Graphe des demandes non compatibles

Une autre approche, propre à faciliter la gestion des contraintes serrées, vise à exploiter les contraintes d’exclusion mutuelles portant sur les demandes.

Coloration d’un graphe de demandes non compatibles. Soient Di et Dj deux de-

mandes dans D. Nous pouvons préalablement tester les 6 combinaisons de tournées, initialement vides, que peuvent induire ces deux demandes :

— Γi,j₁ = {DepotD , oi, di, oj, dj, DepotA},

— Γi,j₂ = {DepotD , oi, oj, di, dj, DepotA},

— Γi,j₃ = {DepotD , oi, oj, dj, di, DepotA},

— Γi,j₄ = {DepotD , oj, dj, oi, di, DepotA},

— Γi,j₅ = {DepotD , oj, oi, dj, di, DepotA},

— Γi,j₆ = {DepotD , oj, oi, di, dj, DepotA}.

Dans le cas où aucune de ces tournées n’est valide, nous disons que Di et Dj

sont non compatibles et nous le notons NonCompatible(i,j). Nous notons également GrapheNonCompatible = (D,NonCompatible) le graphe des demandes ainsi induit par la relation NonCompatible. Toute solution réalisable d’une instance DARP induit alors une coloration de graphe à K couleurs.

Figure 3.7 – GrapheNonCompatible avec deux véhicules et deux demandes

Supposons maintenant que les tournées Γ1..ΓK ont été partiellement construites.

Ceci induit une coloration partielle de GrapheNonCompatible. Il est alors possible : — d’appliquer à cette coloration partielle des règles de propagation permettant

de l’enrichir ou de déduire une impossibilité ;

— de tester l’existence d’une coloration de Graphe NonCompatible, qui prolonge cette coloration partielle, et déduire, soit une impossibilité, soit une préconi- sation sur la demande à insérer.

L’existence d’une telle coloration peut être testée par une simple recherche arbo- rescente. Coloration, l’algorithme 14, effectue cette recherche à partir de l’ensemble H des demandes non traitées, et de la collection (Dom = Dom(i), i ∈ H) qui fournit,

pour chaque demande i de H, l’ensemble des couleurs (véhicules) encore possibles. Coloration nous renvoie tout d’abord un booléen nous informant de la réussite ou de l’échec de la recherche, une fonction colorante γ(i) avec i ∈ H, si elle existe, et une liste de clauses contenant des expressions logiques exprimant des contraintes additionnelles sur les colorations possibles. C’est cette partie du résultat qui fournit des indications sur la prochaine insertion à effectuer. Nous ne parcourons pas l’en- semble de l’arbre : ceci prendrait trop de temps, et, de plus, nous devons appeler fréquemment la procédure de coloration. Les règles d’inférence que nous utilisons, lors de la coloration d’un nœud i0 par k0, sont :

— R1* : |Dom1(i)| = 1 et γ(i) non assignée |= γ(i) prend l’unique coloration k

et i est insérée dans J0;

— R2* : i, i0 ∈ H et k ∈ K sont tels que γ(i) = k, k ∈ Dom1(i0) et nous avons

N onCompatible(i, i0) |= k est enlevé de Dom1(i0) ;

— R3* : i ∈ H et k ∈ K sont tels que k ∈ Dom1(i) et k n’appartient à aucun

sous-ensemble Dom1(j), j ∈ H − J0 |= attribuer k à γ(i) et insérer i dans J0;

— R4* : i ∈ H, Dom1(i) = N IL |= Succes ← F AU X ;

Algorithme 14 Coloration

Entrées: les demandes H non traitées et chacun de leur domaine réalisable Dom : (H,Dom) ; Sorties: le booléen SuccesColoration, la fonction de coloration γ, la liste de clauses Cl :

(SuccesColoration,γ,Cl) ;

1: Si H=Nil Alors

2: Retourner (VRAI,Nil,Nil) ; 3: Sinon

4: choisir i0∈ H ; Continue ← V RAI ; choisir une sous-liste L ⊂ Dom(i0) et l’ordonner. On

appelle L la liste de balayage ; ListeInterdits ← N il ;

5: Tant que Continue et L 6= Nil Faire

6: Res ← F AU X ; k0 ← T ete(L) ; L ← ListeSansT ete(L) ; Dom1 ← Dom ; J0 ← {i0} ;

Succes ← V RAI ;

7: appliquer les 4 règles d’inférences R1*,R2*,R3* et R4* ; on récupère la mise à jour de Dom1 ainsi que le booléen Succes dont la valeur a pu être inversée en R4* ;

8: Si Succes Alors

9: (SuccesColorationAux, γAux, ClAux) ← Coloration(H − J0, Dom1) ;

10: Si SuccesColorationAux Alors

11: Continue ← F AU X ; succesColoration ← V RAI ; γ ← γAux∪ {γ(i0), γ(i0) = k0} ∪

{γ(iR), γ(iR) tel qu’il y a affectation de couleur en iR dans les règles R1* ou R3*} ;

Cl ← {γ(i0) 6= k, k ∈ ListeInterdits} ∪ {(γ(i0) = k0) ⇒ c, c ∈ ClAux} ;

12: Sinon

13: on insère k0dans ListeInterdits ;

14: Fin si

15: Sinon

16: on insère k0dans ListeInterdits ;

17: Fin si

18: Fin tant que

19: Retourner (Res,γ,Cl) ;

Explications. La première règle R1* affecte directement un véhicule à une demande si celle-ci ne dispose plus que d’un seul véhicule pour la prendre en charge. R2* met de façon triviale Dom(i), i 6= i0. Ensuite, R3* affecte un véhicule à une demande si

celui-ci n’est présent dans aucun autre ensemble Dom. Enfin, la règle R4* informe des cas de non faisabilité de la prise en charge d’une demande avec le graphe courant de non-compatibles.

Remarques. Coloration est une heuristique, l’instruction en ligne 6 la rend exacte si le domaine réalisable de i0 est entièrement inclus dans la liste. Il faut garder à l’esprit

que, dans la plupart des cas, il existe une coloration et que celle-ci peut-être obtenue avec un petit nombre de "retour-arrière" - ang. backtrack -. L’instruction (I1) qui indique le choix de la demande "à colorer" applique le principe de la variable la plus contrainte. Autrement dit, les demandes qui semblent avoir le plus de difficultés à s’intégrer dans une tournée (i.e. |Dom(i)| est le plus petit) sont sélectionnées en (I1) de manière prioritaire.

Les clauses résultant de coloration sont sauvegardées afin d’être utilisées lors de l’appel suivant de la procédure Coloration, pour identifier les demandes et les véhicules les plus contraints lors du processus d’insertion.

Exemple. La figure 3.8 représente un exemple de graphe de non-compatibles. Les couples de demandes (A ;B), (A ;C), (B ;C), (B ;D), (C ;D) ne pouvant pas être pris en charge par le même véhicule sont reliés par une arête. Les domaines réalisables sont donnés dans la figure, trois véhicules sont disponibles : K = (1 ;2 ;3).

Figure 3.8 – Coloration : état initial et final de l’exemple

Toujours pour cet exemple, nous relevons la trace du processus de coloration en y intégrant l’apparition des différentes clauses logiques partant de A = i0 :

1. γA ← 1 (R1*),

2. Dom(B) = (3) et Dom(C) = (2) ; (R2*),

3. γB ← 3 puis Dom(D) = (1; 2) ; (R1*) puis (R2*),

(a) une clause est insérée : γA= 1 ⇒ γB = 3 ;

4. γC ← 2 puis Dom(D) = (1) ; (R1*) puis (R2*),

(a) une clause est insérée : γA= 1 ⇒ (γB ← 3) ∧ (γC ← 2) ;

5. γD ← 1 ; (R1*),