-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PROBLEME PROPAGATION INITIALE #28
Comments
Plus précisément : Le delta de mon ArcEventRecorder contient les valeurs déjà traitées dans la propagation initiale Ce problème concerne à coup sûr les Variables Graphes mais comme la machinerie des Recorder est la même (en gros seuls le DeltaMonitor change) il est possible que ce problème touche aussi les IntVar Ceci se produit donc lorsque
Charles, tu me manques! |
Chers amis, je vais poursuivre mon monologue avec un exemple simple : Propagation initiale de P1 => NB=1 alors que x={1,2} Je n'ai pas encore codé cet exemple mais d'après ce que j'ai vu dans le code je pense qu'il y a réellement un J'en revient donc à ce que j'ai dit précédemment : "un propagateur ne devrait se réveiller qu'aux évènements qui sont postérieurs à sa propagation initiale" |
J'ai pour le moment un moyen de résoudre le problème mais il n'est pas encore très satisfaisant : j'introduit une nouvelle méthode "initialPropagation()" dans l'interface IDeltaMonitor @OverRide //(IntDelta) @OverRide //(GraphDelta) Au début de chaque propagation initiale d'un propagateur Pi, on applique cette méthode sur tous les FineEventRecorders de Pi. Par contre ça ne fonctionne pas tel quel car le "clear()" des deltas des "requêtes" est fait de manière LAZY et uniquement une fois la propagation initiale finie (tant que la propagation initiale n'est pas faite le propagateur n'est pas actif). Donc on remet à 0 l'index "first". Pour le moment ma rustine consiste à ajouter un "if(firstClear())" dans la méthode clear() ce qui n'est pas terrible mais mieux que rien. Mais je pense qu'on pourrait modifier la gestion des clear(). De toutes façons, à termes je rebasculerai sur un clear NON LAZY. |
Problème résolu
Reste le problème de la gestion des vues à domaines qui est discutée dans une autre issue |
Bonjour,
j'ai un gros soucis avec la propagation initiale de deux propagateurs A et B:
supposons que dès la pose de mon modèle, certaines de mes variables soient instanciées, elles ne vont pas générer d'INSTANTIATION EVENT, juste?
Du coup pour les traiter dans le propagateur B je dois itérer sur mes variables instanciées durant la propagation initiale de B.
Malheureusement j'ai propagé A avant B et la propagation initiale de A a générée de nouvelles variables instanciées, lesquelles vont à la fois apparaître dans la propagation initiale de B et dans les "requests" de B...??!!
Du coup je fais le boulot 2 fois et ça ne va pas du tout.
Il me semblerait qu'un propagateur ne devrait se réveiller qu'aux évènements qui sont postérieurs à sa propagation initiale, non?
Si c'est sensé déjà être le cas alors il me semble (je peux me tromper) que ça a été récemment cassé.
Sinon, ... pour quelles raisons n'est-ce pas ainsi?
Merci bien et bonne vacances!
The text was updated successfully, but these errors were encountered: