Excellent! :-) I think we can merge this. BTW, for future changes to the open
lists and/or lazy search, we should include the "lama-first" configuration in
the experiments. "seq-sat-lama-2011" (the anytime version) and "lama-first" (the
first algorithm run by seq-sat-lama-2011) are our best configurations for
satisficing planning, and they use lazy search. But I don't think it's necessary
to run new experiments just for this. (Although I would be curious if we also
get 64-bit improvements for lama-first with this new code.)

Here are the results of the experiments with 64-bit. The experiments show that
the memory consumption decreases with the operator IDs.

http://ai.cs.unibas.ch/_tmp_files/geissmann/issue696-v1-sat-m64.html

http://ai.cs.unibas.ch/_tmp_files/geissmann/issue696-v1-sat-m64-issue696-base-issue696-v1-compare.html

Here is the pull request https://bitbucket.org/cgeissmann/downward/pull-requests/2

And I will run the experiments for 64-bits.

I would suggest already running 64-bit experiments now, as I think the hash
table changes are more or less independent, and I'd be happier to merge this
with the 64-bit version already tested.

Cedric, can you please link the pull request here? I already had a look locally and 
the code looks good to me.

Here are the results of the experiment:

http://ai.cs.unibas.ch/_tmp_files/geissmann/issue696-v1-sat-issue696-base-issue696-v1-compare.html

This experiment is only for the 32-bit configuration. The experiments do not
show a decrease in performance, so it should be save to merge. I think further
experiments should be run with the 64-bit configuration when the new
hash-function is implemented (issue213).

This may be a lot of work because the open lists are implemented as templates.
It might mean that we require template specializations for all open lists. I
think we should look at the code first and then decide how to implement this.

Cedric agreed to take over this issue. We'll try to keep the interface as it is for 
now and change it to accepting IDs in a separate issue.

Split off from issue213.

"[We want to] replace the generating operator pointer in
lazy open lists with an operator ID, similar to the change for SearchNodeInfo.
We might then also want to change the interface so that it works with these IDs
and we don't have to convert back and forth between operator pointers and IDs
when we actually use IDs on both ends."

We decided against doing this change as part of issue688, but I think it would be 
easiest if we could merge issue688 before starting to work on this issue.