Split off from issue120.
The following pasted from msg516 in that issue:
==========================================================================
Actually, there are a bunch of useful things that could be done by problem
transformations or problem adapters. Some of them could be under the control of
the user, others could be under control of the heuristics.
Example under control of the heuristics: some heuristics (at least h^cea)
compile the goal away to simplify their implementation. This could be one kind
of general problem transformation that is implemented in such a way that it is
also useful for others who want it. This is best implemented using some kind of
adapter that doesn't modify the original problem (since we don't want to compile
goals away everywhere -- some people, like the goal count heuristic, might like
having the original goal around) or copy the problem (since that's a waste of
time and space).
An example under control of the user would be a transformation that compiles
landmark tracing into the problem so that the heuristics can than make use of
the enriched problem, as in Matthias's Studienarbeit or the paper by Carmel,
Michael and Sagi.
I think there's a lot of potential there, but I'd see that in beyond-1.0
territory and would prefer sticking to the base class approach for now. If there
are other preferences, I'm open to discussion though.
==========================================================================
Different treatments of action costs in the heuristics, such as the three LAMA
variants (original cost, unit cost, original cost plus 1) could also be readily
implemented with different "problem views".
One generic way to implement that would be to give each heuristic an additional
"problem" parameter (or whatever) which would be optional and default to the
actual problem. But one could also apply transformations to the original
problem, either directly within the argument to the call or in an external
declaration as with heuristics:
--problem prob1=compile_in_landmarks(ignore_action_costs(the_problem))
--search lazy_greedy(ff(problem=prob1), hcea(problem=prob2), hcea())
This would alternate between three heuristics:
* h^FF applied to a transformed problem where landmark achievement is tracked
by state variables and all actions have unit cost
* h^cea applied to the same transformed problem
* h^cea applied to the original problem (i.e., taking costs into account and
without compiling landmarks in)
|