I ran a lazy greedy blind search, lama-first, and a lazy weighted A*
search with a weight of 5 and h^FF as a heuristic and for preferred
operators.
There were some issues on the grid with a couple of tasks (I suspect
most of this is caused by VAL crashing on some PSR plans). Across the
~15000 runs, 5 changed between running out of memory and running out of
time (in both directions). I think this could reasonably be tasks that
are close to both limits. Other than that, I don't see a large
difference in time or memory, and no difference in the
expanded/evaluated states or coverage.
http://ai.cs.unibas.ch/_tmp_files/pommeren/issue747-v1-issue747-base-issue747-v1-compare.html
I think we can merge this.
Looks plausible, I'll leave it to the experiments to show the details. :-)
The suggested experiment looks good, but please also include a configuration
with reopening, e.g. using lazy weighted A*.
I prepared a pull request on Bitbucket for this:
https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/38/issue747/diff
Its a nice local change and actually makes the code shorter by 4 lines. The new
code should be equivalent but lookup_state is now called twice. I don't think
this matters, as it is basically an array access.
I also switched
"if (reopen) {...} else if (initial state) {...}"
to
"if (initial state) {...} else if (reopen) {...}"
The two cases are mutually exclusive but even if they were not, the new version
would be the way to go anyway.
What kind of experiments should I run for this? Would lama-first and blind on
the satisficing suite be OK?
The lazy search creates a dummy parent for the initial state which causes issues
with the switch to the task interface. Rather than working around the hack, I
would like to try and remove it by handling the initial state separately from
other states.