The issue is now merged.

OK, with the follow-up change for iPDB, I have no further comments. From my
perspective, this is ready to merge.

Thanks! The only results that look a bit odd to me are the ones for iPDB, where
the number of evaluations increases significantly, and runtime also increases
very much in some tasks. Do we know why this is the case? Maybe it's related to
the comments for the PDB heuristics I made on Bitbucket?

Apart from this, it all looks good to me. I quickly went over the code on
Bitbucket. As you say, there are some rough corners at the moment, but I think
it's still a big step into the right direction.

I ran experiments with the merge from issue544 now, here are the results:

Comparison reports:
http://ai.cs.unibas.ch/_tmp_files/simon/issue108-opt.html 
http://ai.cs.unibas.ch/_tmp_files/simon/issue108-sat.html

Relative Scatterplots for search time and memory:
http://ai.cs.unibas.ch/_tmp_files/simon/issue108-opt-relativescatter.zip
http://ai.cs.unibas.ch/_tmp_files/simon/issue108-sat-relativescatter.zip

I think the results look ok, although I'm not entirely happy with the search
time. There are also two small things in the code that maybe could be done
better, but I commented on them in the pull request already.

OK, as mentioned elsewhere I'd wait with the code review until we have
experimental results, so let's wait for issue544 then. I think it should be
merged very soon.

There might be an explanation for the different expansions in some
configurations: As far as I could tell all configurations with different
expansions use some kind of relaxed planning, and issue544 shows that using
preferred operators with delete-relaxation heuristics leads to non-determinism.
I would suggest that I run the experiments on these configurations again once
issue544 is fixed.

Since the first point of this issue has been done already and provides a nice
interface for storing arbitrary per-state information in heuristics I
implemented steps 2 and 3 now. The pull request is here:
https://bitbucket.org/salome_simon/downward-issues/pull-request/2/caching-heuristic-estimates-in-heuristic/diff

Each Heuristic has a PerStateInformation where it can caching heuristic
estimates. There is also a flag which allows to turn off caching (e.g. for blind
heuristic this would make sense). The .h field in SearchNode is also gone now.
You can access the h values for a certain state with help of an
EvaluationContext (which will either (re)calculate the value if it is not stored
or dirty, or return the cached value)

I started some experiments as well, the satisficing results are already done:
http://ai.cs.unibas.ch/_tmp_files/simon/issue108-base-issue108-v1-compare.html
(a zip archive with all reporst is here:
http://ai.cs.unibas.ch/_tmp_files/simon/issue108_sat.tar)

I am somewhat confused why the expansions are different in some domains, I think
my changes should not change the number of expansions (the number of evaluations
can be different when reopening because the old code recomputed the heuristic
estimate while the new code takes the cached value if caching is enabled). I
will take a look into this.

We want to implement heuristic caching as follows:
1. Each state will be assigned an id by SearchSpace. These will be consecutive.
2. Each heuristic will have a vector, where the heuristic value for
each state will be saved (according to the id)
3. Then we can get rid of the .h field of SearchNodeInfo, and reuse heuristics 
much better