Title task class: add task transformations
Priority feature Status resolved
Superseder Nosy List florian, jendrik, malte
Assigned To jendrik Keywords
Optional summary

Created on 2015-02-20.17:50:17 by jendrik, last changed by jendrik.

msg4028 (view) Author: jendrik Date: 2015-02-27.14:57:34
Merged and pushed.
msg4025 (view) Author: malte Date: 2015-02-23.16:53:59
OK, had a look at the code; no obstacles to merging. What is still missing is
some kind of documentation of the overall design, though: which classes exist,
what is their interplay, how is user code supposed to work, etc.
msg4024 (view) Author: malte Date: 2015-02-23.16:38:01
Looks OK to me. Some nontrivial slowdowns for blind search, e.g. in Scanalyzer,
but I think nothing that needs to keep us up at night. I'll have another look at
the diff and then write again.
msg4023 (view) Author: jendrik Date: 2015-02-23.11:47:08
The experimental results are in:
msg4021 (view) Author: malte Date: 2015-02-20.17:57:56
Recording the rationale that led to this issue:

There are some stumbling blocks with the current code w.r.t. bridging between
different task classes. For example, if the search algorithm uses task t1 and
uses a heuristic that is based on task t2, then the heuristic must be able to
take a state of t1 (provided by the search) and map it to a state in task t2
(used for heuristic computation).

There are some dangers lurking there, e.g. when we want to use the same
heuristic in multiple searches (that might work with different tasks). For our
next steps, we have decided to deal with this as follows:

- For now, only the heuristics work with the new task class and hence
potentially on a transformed view of the "global" task. For now, the search
algorithms keep working on the original unmodified tasks using the GlobalState,
GlobalOperator etc. classes.

- We will grow functionality for bridging between the global task and the task
proxy objects used by the heuristics. For now, we at least need to do two
conversions: converting "global" states to states of the heuristic (for the
input to the heuristic computation) and converting operators/operator IDs used
by the heuristic to "global" operators (for reporting preferred operators).

This will be done by a separate TaskTransformation mechanism. The base heuristic
class will deal with the conversion; the derived heuristic classes do not need
access to the transformation and should not be able to "see" any global states
or global operators.

- The heuristics will receive task transformations as their arguments, not the
resulting transformed tasks themselves.

- These points imply that for now, it won't be possible to nest transformations
(because they always map from the implicit global task to abstract tasks, rather
than mapping between arbitrary potentially transformed tasks). For now, we see
this as a feature rather than a limitation because it helps us change the
heuristics to work on the abstract tasks without having to think about the
complications that can arise if the searches also work on arbitrary unknown
transformed tasks. Once we have collected more experience with the new task
class based on the heuristics, the goal is to also use it elsewhere (e.g. for
the search), but this will be a later step.
Date User Action Args
2015-02-27 14:57:34jendriksetstatus: chatting -> resolved
messages: + msg4028
2015-02-24 12:15:13floriansetnosy: + florian
2015-02-23 16:53:59maltesetmessages: + msg4025
2015-02-23 16:38:01maltesetmessages: + msg4024
2015-02-23 11:47:08jendriksetmessages: + msg4023
2015-02-20 17:57:56maltesetstatus: unread -> chatting
messages: + msg4021
2015-02-20 17:50:17jendrikcreate