Merged and pushed. Thanks to everyone involved!

Exactly, the mystery task is proven unsolvable (or not) very near to the time 
limit.

Thanks! Code looks good. Regarding the results, I'm surprised by the change in
the evaluation score -- seems there is an additional task solved, which improves
the score, but coverage remains the same. Is this because the task is proved
unsolvable? (That's in the mystery domain.)

I had a quick look at the diff; looks fine. I think the h^m issue was the only
thing bothering us, so it looks ready to merge.

We can use a hidden bitbucket feature (https://bitbucket.org/site/master/issues/4779/ability-to-diff-between-any-two-commits):

v1: non-inlined code
v2: inlined code
v3: print function for FactPairs, get_fact_pairs(), cleanup

base -> v1
https://bitbucket.org/jendrikseipp/downward/branches/compare/issue635-v1..issue635-base#commits

v1 -> v2
https://bitbucket.org/jendrikseipp/downward/branches/compare/issue635-v2..issue635-v1#commits

v2 -> v3
https://bitbucket.org/jendrikseipp/downward/branches/compare/issue635-v3..issue635-v2#commits

Is there a way to see a diff to the previous 
version, i.e., the one with the previous 
experiments?

I made a profile, but didn't spot anything that stood out.

Next, I inlined the code in FactPair and ran an experiment. That seems to be the difference for h^m:

http://ai.cs.unibas.ch/_tmp_files/seipp/issue635-v2-issue635-base-issue635-v2-compare.html

Time scores are now up-to-par with the base version. (Expansion scores for this experiment and the one 
below vary only for a single mystery instance, that is proven unsolvable in the initial state very close 
to the timeout. Sometimes the instance is solved within the timeout and sometimes it isn't.) 

While I was at it, I also used the new FactProxy::get_pair() method to simplify the h^m code and cleaned 
it up a bit. Additionally, I merged the default branch into the issue branch to resolve some merge 
conflicts.

Results for this version look good as well, but maybe it would be good if someone could have a look at the 
changes in hm_heuristic.* and task_tools.*.

http://ai.cs.unibas.ch/_tmp_files/seipp/issue635-v3-issue635-base-issue635-v3-compare.html

I made a new pull request to which the whole group has access:

https://bitbucket.org/jendrikseipp/downward/pull-requests/56

@ Cedric: Sorry for hijacking this issue, I got carried away a bit ...

We talked about the experimental results offline and found that we need to 
profile a task for which h^m takes significantly longer in the new
version (e.g. with valgrind's callgrind and kcachegrind) to find
out why the new h^m version is slower.

Cedric has made a pull request at 
https://bitbucket.org/cgeissmann/downward/pull-requests/1
and from my point of view the code looks ready to be merged. 

We also ran some experiments (with a 10 minute timeout) for the affected heuristics (hm, ipdb, cea, cg) on the 
optimal_strips benchmark set, using the latest version of each domain if it was used in multiple IPCs.

http://ai.cs.unibas.ch/_tmp_files/seipp/issue635-v1-issue635-base-issue635-v1-compare.html

The new h^m version uses slightly more time and the new h^cea solves 2 tasks less (the old version solves them in 
just under 10 minutes), but I don't think these are reasons not to merge the code.

Here are relative scatter plots comparing the total time for each heuristic:

http://ai.cs.unibas.ch/_tmp_files/seipp/issue635-v1-issue635-base-issue635-v1-total_time-cea().png
http://ai.cs.unibas.ch/_tmp_files/seipp/issue635-v1-issue635-base-issue635-v1-total_time-cg().png
http://ai.cs.unibas.ch/_tmp_files/seipp/issue635-v1-issue635-base-issue635-v1-total_time-hm(m=2).png
http://ai.cs.unibas.ch/_tmp_files/seipp/issue635-v1-issue635-base-issue635-v1-total_time-ipdb().png

What do you think, Malte?

As discussed in our meeting these would be the first steps:

- rename Fact struct to FactPair
- add FactProxy::get_pair() method
- grep for "pair<int, int>" in "pdbs" directory and replace the occurences that 
represent facts by FactPair instances.

issue499 added the Fact struct and issue621 used it for the task interface. This 
issue should be concerned with using the Fact struct in the remaining places in 
the code where we currently use pair<int,int> to store facts.