I ran sanity tests with the affected heuristics. Nothing in the behaviour has
changed so we seem to compute exactly the same heuristics as before.

Malte already had a look at the changes, so I merged this.

off the track*er*

We've discussed this off the track; for posterity: Regarding C., only
considering pre->eff arcs is the right thing. No need to add options here,
either now or later.

I had to fix a bug in the new causal graph implementation because it did not
consider effect conditions.

Experiments are running...

IIRC, there are two kinds of graphs that are interesting here:

1. The "pre->eff graph". This contains arcs u->v iff u != v and there is an
operator with u as a precondition or prevail condition variable and v as an
effect variable.

2. The "causal graph". This contains the same arcs and additionally arcs u->v
iff u != v and some operator has u and v as an effect variable.

The legacy causal graph is the pre->eff graph. Our new causal graph class
supports all kinds of different definitions. Right?


If yes, then:

A. The CG heuristic should use the pre->eff graph. It cannot do anything useful
with eff->eff arcs.

B. For the iPDB pattern generation methods (called "haslum" in the code),
pre->eff graphs make sense and should be preserved. The question is whether we
additionally want to add an option that allows using eff->eff arcs. In the
search neighborhood we use, using eff->eff arcs only makes sense if the newly
added variable has a defined goal. Otherwise it cannot offer a better heuristic
value than the current pattern and hence will never be selected. At least that's
what I think -- it would be good if someone else could verify this thought and
if we could add a comment to the code if we implement this option. (I think it
would be useful to have it since it could potentially improve our PDB heuristics.)

C. Don't remember the GA-PDB ("edelkamp") method well enough to really comment.
Shall I have a look?

D. Variable orders: we don't really know much about good variable orders. It's
probably a good idea to include both options (pre->eff and causal) wherever they
both make sense and play around with them a bit. Silvan can probably help
conduct meaningful experiments with M&S. (I think this is the only part of the
code where the variable order really matters at the moment.) If we want to use
both, which I would advocate in this case, a natural way of naming would be "CG"
for the causal graph and "preeff" (or a better name?) for the pre-eff graph. The
problem with this is that we *currently* use "CG" for the "pre-eff" graph. This
is misleading: this isn't how papers define the causal graph. My suggestion: do
away with the current name entirely and offer the two options "causal" and
"preeff" so that noone can use the wrong version accidentally.

All this may look like more work than it's worth (although I think at least the
additional variable orders might be interesting to have around), in which case
we can split this into two parts, with the new features to be deferred until later.

If I see this correctly, the old causal graph is used by the causal graph
heuristic, the variable order finder of merge and shrink and the pattern
generation methods "haslum" and "edelkamp".

Malte, do you have any comments on this issue, e.g. whether we should preserve
exactly the same behaviour as before or whether we can gain something from
exploiting the new causal graphs?

We should get rid of all traces of the legacy causal graph (issue89) and remove
it. Future changes to the file format should no longer include the causal graph
information (issue371).