After small changes in the documentation and some small refatorings, performance
did not change:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue595-v1-issue595-v3-compare.html

Merged and pushed.

Thanks!

I changed the title because I wanted to polish and fix a few small issues here
and there, and the originally thought "bug" in DFP does not require any fix.

> The experiments after the refactoring are fine, but I found something
> strange with the translator/preprocessor: when translating with the baseline
> revision, the output generated for trucks-strips/p19.pddl differs from the v1
> version, but none of the files of the translator or the preprocessor differ.

This is normal: the translator output for trucks-strips is not fully
deterministic (for the larger tasks) because the time limit on invariant
synthesis is reached. The result then depends on how many/which invariants could
be found until the time limit. If the run is a bit faster or slower than usual
(because of which other things run concurrently on the machine etc.), we can
find perhaps one or two more invariants, and this affects the SAS+ encoding.

It's a bit unfortunate and one of the drawbacks of using whole-planner
experiments instead of the old preprocessed-once stuff. But trucks-strips is the
only domain we have that has this property.

Changing the order in which transition systems are considered by DFP from "last"
to "first" pair for tie breaking slows down performance a bit, hence I reverted
the change.

http://ai.cs.unibas.ch/_tmp_files/sieverss/issue595-v1-issue595-v2-compare.html

I attached both log files.

The bug I thought of turned out not to be a bug.

The experiments after the refactoring are fine, but I found something strange
with the translator/preprocessor: when translating with the baseline revision,
the output generated for trucks-strips/p19.pddl differs from the v1 version, but
none of the files of the translator or the preprocessor differ.

http://ai.cs.unibas.ch/_tmp_files/sieverss/issue595-base-issue595-v1-compare.html

This is part of meta issue567.

I'd like to fix a bug in the computation of label ranks and also take the
opportunity to precompute the current order of indices in which we compute label
ranks, to ease future variants of DFP which randomize or invert this precomputed
order.