merged

Results look good to me. I haven't seen this type of critical error before, and
it would be good to know what is going on there, but they indeed look unrelated
to this issue.

There were three critical errors in the translator but since I didn't touch it,
I assume that is unrelated.


Other than that, results look quite good, I think:
https://ai.dmi.unibas.ch/_tmp_files/pommeren/issue835-v1-issue835-base-issue835-v1-compare.html

Left one comment on bitbucket. If the experiments succeed, it looks good to
merge for me.

This is now ready for review in the following pull request:
https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/49

A short 5-minute experiment with lama-first is running to verify that
performance is not affected too much.

We discussed this and decided that for now, we only want to change the method
get_global_operator_id that is used to translate OperatorIDs up the hierarchy
for preferred operators. Currently, it always translates its argument all the
way up to the root of the hierarchy. We want to add a TaskProxy argument and
only translate up to that task. This way, we can also fail if the target is not
an ancestor in the hierarchy. I also suggest renaming the method to
convert_operator_id to match convert_state_values.

The argument to this method would then be g_root_task in all places where it is
currently used. This is fine for now as long as the search always uses the root
task (see msg7659). We have to solve the component coordination problem
(isse559) before being able to get rid of g_root_task here. 

I changed the title to represent the change in scope.

For future reference, this issue probably needs a pointer to one of the other
issues where we talked about this topic further.

Can this work? Because evaluators are predefinable, the same evaluator can be
used in multiple searches with different tasks.

I think it is important here that we think of the "transform" arguments of
heuristics as task *transformations*, not tasks. A task transformation is a
mapping from task X to task Y, so users of a transformation should have some way
of accessing information about both task X and task Y at some level.

I think the whole idea of task transformations currently only exists at the
conceptual level, and therefore we cannot currently implement this properly. In
particular, it is probably wrong that the "transform" option of heuristics is
"AbstractTask". It should rather be "TaskTransformation", which currently
doesn't exist in the code. I would think of task transformation as a kind of
factory function that takes task X and produces task Y.

There may or may not be some conceptual analogy here to the fact that the option
parser gives us OpenListFactory, not an actual open list, and similarly for
landmark factories.

The heuristic currently converts operator IDs of its local task to IDs of the
root task before storing them as preferred operators. This is only correct if
the search uses the root task. Currently, it does but in the long run we want to
allow other tasks in the search.

The heuristic should assume that its task is a transformed version of the search
task and only convert the operator IDs up to the level of the search task. To
that end, the heuristic has to know the search task. Alternatively, the
conversion has to happen outside of the heuristic.

I suggest we add a TaskProxy parameter "search_task" to the heuristic ctor and
store it. When converting the IDs, we use a method similar to that for
converting states. It should fail with an error if the search task is not an
ancestor of the heuristic task.