Les masques des propagateurs

[cprudhom]

Les masques de propagation interviennent à plusieurs endroits:

• à quoi réagit un propagateur,
• caractérisation d'une modification de variable,
• caractérisation des modifications appliquées à une variable pour l'exécution d'un propagateur

Le treillis défini par Schulte est une base de travail mais il reste des questions:

• le masque de modification d'une variable doit-il contenir les événements induits ou
• ces événements induits doivent-ils être reconstruits dans le propagateur?

Dans le premier cas, on noie les informations, dans le 2ème cas on compte sur le développeur du propagateur.

[chocotrust]

On peut peut-être rappeler ce que sont les masques. Lors de la propagation, des événements se produisent sur les variables : retrait de valeur, modification de borne, trous dans le domaine, instanciations, etc. La notion de masque permet d'encoder les modifications survenues pour les traitements (ce que tu dis : réaction des propagateurs, caractérisation des modifications).

Le souci, à mon sens, vient du fait qu'un même événement peut induire plusieurs lectures : un retrait de valeur peut aussi être une modification de borne et aussi une instanciation par exemple. J'appelle ceci de la promotion dans la suite. Le masque permet de les encoder tous. La question reste de comment traiter ce masque ...

• si la variable elle-même assure la "promotion", le masque en sortie contient tous les événements qui se sont produits suite à une modification. Il faut alors les traiter en ayant bien en tête que certains événements en contiennent d'autres.
• si la promotion n'est pas assurée, chaque propagateur doit avoir en tête qu'il peut y avoir eu promotion

Je ne suis pas sûr qu'il y ait une "bonne" réponse. Par contre, quel que soit le choix fait, il faut fixer des règles de développement :

1/ si le masque contient tous les événements, il est probablement conseillé d'avoir des propagateurs qui soit en traitant un événement traitent tous les autres, soit qu'il soit bien clair que le traitement d'un type donné d'événement n'assure pas du tout le traitement des autres (concrètement, on verra le traitement du masque comme des if else if dans le premier cas ; des séquences de if dans le second ...)

2/ si le masque ne contient pas la promotion, cela complexifie je pense la production de propagateurs ... il faut gérer en interne la promotion ; c'est probablement très simple pour beaucoup de contraintes mais aussi très complexe pour d'autres ...

[jgFages]

Pour moi le masque définit les modifications qui ont eu lieu. Le propagateur doit réagir, maintenir ses structures, lancer certains algorithmes ... en fonction de ces modifications, qu'elles soient induites ou non. Il me semble donc important de ne pas écarter les évènements induits.

Exemple: si je fais un mapping entre un graphe et des variables entières je ne réagis qu'aux suppressions de valeurs (=> je supprime les arcs associés). Pour moi une borne ne signifie rien, je n'en veux pas... Donc si une valeur extrémale (i.e. une borne) est supprimé par une contrainte annexe qui a décidée de faire un updateBound(...), je veux avoir un évènement de retrait de valeur et que cette suppression figure bien dans le delta des valeurs retirées. C'est crucial pour le maintient incrémental de certaines structures.

Voyez-vous un intérêt à ne pas inclure les évènements induits dans le masque? (donner un exemple)

Pour rebondir sur Naren (waou) 1/ si le masque contient tous les événements, il est probablement conseillé d'avoir des propagateurs qui soit en traitant un événement traitent tous les autres, soit qu'il soit bien clair que le traitement d'un type donné d'événement n'assure pas du tout le traitement des autres (concrètement, on verra le traitement du masque comme des if else if dans le premier cas ; des séquences de if dans le second ...) => Je suis plutôt pour la séquence de if() Avez-vous un exemple justifiant le if, else if, elseif ... else?

[chocotrust]

Je suis d'accord avec JGF (waou). Je ne vois pas d'intérêt de ne pas inclure les événements induits et je suis aussi plutôt favorable aux séquences de if.

[cprudhom]

En fait le problème est plus simple qu'il n'y parait.

• on est d'accord qu'il faut garder la promotion (si suppression de l'avant dernière valeur d'un domaine, alors l'événement est INSTANTIATION et non plus REMOVE) parce que sans ça on perd en efficacité sur les réactions aux événements (il faut par exemple, tester si une variable est instanciée, si sa borne est modifiée, etc.).
• on est également d'accord qu'il faut garder les masques d'abonnement des contraintes, pour ne réagir qu'aux événements auxquels le propagateur sait/veut faire quelque chose.

Alors il faut absolument proposer les événements agrégés et induits au propagateur lors de la propagation, sinon les 2 précédents points sont incompatibles.

[chocotrust]

OK reste une dernière question : le propagateur quand il traite un événement traite-t-il tous les événements induits possibles ? Si oui, on peut utiliser un if else if pour traiter les différents cas ; si non, il faut une séquence de "if" (ma solution préférée)

[cprudhom]

Je crois que c'est plutôt au développeur du propagateur de décider, non? Il reçoit les événements (agrégés) induits, au propagateur de savoir quoi en faire et comment. Tu veux donner des règles pour ça?

[chocotrust]

On peut laisser ça au développeur en effet mais il faut que les choses soient claires pour lui, qu'il ait en tête la possibilité d'événements induits et de la nécessité de leur traitement (d'une manière ou d'une autre). Il s'agit de ne pas se retrouver dans la situation du bug de l'autre fois

[cprudhom]

Ok, je vais mettre à jour la javadoc, au moins ca sera présent qq part, en attendant d'avoir une doc.

[cprudhom]

J'ai commencé la page suivante finalement: https://github.com/cprudhom/Galak/wiki/Les-propagateurs

[jgFages]

Super. Le problème est donc clos!