Relevant cross references:
issue552 (new task interface for cea heuristic)
issue553 (new task interface for cg heuristic)
issue26 (integration of preprocessor in search code)

After Malte has done the code review, I have merged the changes. Resolved. :-)

Hm, true (regarding Woodworking being STRIPS). The instances from 08 and 11 are
identical, so from these domains there are really only two tasks affected. I
will try to find out what has changed there.

I'll have a closer look later, but isn't the coverage loss mainly from
woodworking (which is STRIPS)? Looking at the evaluation scores for CEA and CG,
most domains seem unchanged, except for one task lost in PSR-Large by CG, which
was 10-20% away from the time and memory limit in the baseline.

Experimental results are now available:
http://ai.cs.unibas.ch/_tmp_files/roeger/issue549-base-issue549-v3-compare.html

The change in the landmark generation method (RHW) is uncritical. With the cg
and cea heuristics we loose a few instances (6 with CG). STRIPS domains are not
affected but there seems to be a negative impact in the presence of axioms.

Malte, you now these heuristics best. Do you have an intuition what could be
going on there?

The implementation is so far completed. As part of this issue, I also ported the
cg and cea heuristics to the new task interface. These are now the only classes
that use the structures from domain_transition_graph.*. I think this makes much
sense, because DomainTransitionGraphs are very much tailored for these
heuristics. The class LandmarkFactoryRpgSasp is only interested in the successor
values in the domain transition graphs and now precomputes this information on
its own.

Once DTGs and min_action_cost can be computed for TaskProxy objects as well they
should replace the global instances that are currently used in the cg_heuristic
(issue553).

There's still some other functionality in the preprocessor (variable ordering
and relevance analysis). BTW, there is an over-arching issue for getting rid of
the preprocessor: issue26. I think it makes sense to have the individual steps
as separate issues, but it's good to have cross-references. I'll add one here;
can you add cross-references for the issue that is about removing the successor
generators?

We want to move the implementation from the preprocessor into the planner
component. After closing this issue and issue547, we can get rid of the
preprocessor.