Title Subscription and notification of path dependent heuristics.
Priority meta Status chatting
Superseder Nosy List florian, jendrik, malte, manuel, silvan
Assigned To Keywords
Optional summary

Created on 2017-04-28.18:25:45 by manuel, last changed by malte.

msg6311 (view) Author: malte Date: 2017-05-02.11:43:31
My suggested answers to Manuel's questions: we should have a registration
mechanism similar to the current "get_involved_heuristics" method (but with a
new name) that recurses through the open lists and evaluators in order to let
them subscribe to notifications about the initial state and transitions.

This registration mechanism should make sure that the same evaluator is only
asked once whether it wants to register, even if it is reached multiple times.
(The same should be true for open lists, but currently it's not possible to have
an open list be used in multiple contexts.)

All evaluators should be able to subscribe, not just heuristics. In particular,
this mechanism might turn out to be useful for implementing g values and "real g
msg6310 (view) Author: malte Date: 2017-05-02.11:38:11
> If you look into use cases you could also check if we can use an OperatorID,
> OperatorProxy, or just remove the parameter.

Even if we don't currently use the operator parameter, I don't think we should
remove it. There are path-dependent heuristics other than the ones used in our
current codebase (for example in Salomé's LTL code), and it doesn't seem
unreasonable that a path-dependent heuristic should receive information about
operators associated with transitions.
msg6308 (view) Author: florian Date: 2017-05-02.10:21:10
A related thing we should look at is what kind of information the notification
should provide. In issue725 I tried to reduce the number of GlobalOperator* and
notify_state_transition is one of them. It currently takes two GlobalStates and
one GlobalOperator*. But the GlobalOperator* is never used (only forwarded). If
you look into use cases you could also check if we can use an OperatorID,
OperatorProxy, or just remove the parameter.
msg6275 (view) Author: manuel Date: 2017-04-28.18:25:45
A path dependent heuristic can subscribe itself to be notified about initial
state and state transitions that are reached during search.

Currently, FD uses subscriptions and notifications as follows:
- All evaluators can subscribe but only heuristics will be notified.
- All heuristics subscribe themselves but not each heuristic requires a

The current use of subscriptions and notifications raises following questions:
- Should evaluators also be notified?
- If yes, should an evaluator notify its sub-evaluators or should sub-evaluators
be directly notified, independent of the evaluator (e.g. SumEvaluator)?
- Which evaluators/heuristics require notification?

We want to evaluate different use cases (e.g. consider notification under
reopening of states) and look at their requirements. Based on those insights, we
wish to define which evaluators can subscribe, how they subscribe, and how they
are notified about the visited search space (e.g. transitions etc.).
Date User Action Args
2017-05-02 11:43:31maltesetmessages: + msg6311
2017-05-02 11:38:11maltesetmessages: + msg6310
2017-05-02 11:21:02silvansetnosy: + silvan
2017-05-02 10:21:10floriansetnosy: + florian
messages: + msg6308
2017-04-28 18:25:45manuelcreate