Thanks for the feedback; merged.

Thanks! I made some comments directly for the two commits (because I wanted to
see the diff between the previous version and the new commits) and some more for
the pull requests. I hope you get notifications for all of these. After these
small comments are addressed, I think this can be merged.

I updated the pull request with the changes to sccs and the changes from the
other comments.

Code review done. Looks like this is done apart from the changes to the SCC
algorithm we discussed.

Great! The pull request is updated.

Hi Silvan, it's FIFO time! Can you bring the pull request up to date, i.e., make
sure that it is based on the most recent master version? If I look at it right
now, I see some small conflicts (e.g. in the CMake files).

I ran experiments for two versions: v1 is the one that matches the paper, but
which uses a hack, and v2 is the "clean" version.

The hack: the previous implementation of DFP (before the refactoring of the
design of merge strategies) did not compute DFP scores for any pair of
transition systems where both were not goal-relevant. With the new
implementation of DFP as a chain of score-based selectors where after each
iteration, only the pairs with the best score remain, we would first "filter
out" all pair that are not goal-relevant, then evaluate the remaining ones with
DFP, before finally using the usual tie-breaking criteria. If there are no
goal-relevant pairs (which is possible when merging an SCC that does not contain
any goal variable), we would compute DFP on *all* pairs, which differs from the
old implementation of DFP. Hence the hack skipped the evaluation with DFP at
this point. 

The following tables are a subset of the full reports (linked below), relevant
for Table 4 of the ICAPS16 paper:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-v1-paper.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-v2-paper.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-compare-v1-v2-paper.html

abp: atomic before product (prefer atomic transition systems over products)
pba: product before atomic (prefer product transition systems over atomics)
rl/l/rnd: order of atomic transition systems (reverse level/level/random)
nto/otn/rnd: order product transition systems (new to old/old to new/random)

The differences between using the hack and not using it is very small, hence we
can safely not use it. Furthermore, like in issue668, the results match those in
the paper, except for the configurations that use RNG-based tie-breaking. Again,
this is due to the change from using a local to the "global" RNG always, and I
think that this is ok.

Full reports:
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-v1-abp.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-v1-pba.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-v2-abp.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-v2-pba.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-compare-v1-v2-abp.html
http://ai.cs.unibas.ch/_tmp_files/sieverss/issue667-compare-v1-v2-pba.html

> I was thinking of a high-level description of what should go where (and perhaps
> why, i.e., the rationale). Something that could help people decide where to put
> things and also help find things and understand the code structure on a high
level.

> Regarding where/how to document it: don't really know. I'll suggest it for the
> next meeting.
issue672 deals with that.

I also pushed the review to the new queue.

> What exactly did you mean by "master documentation on the directory structure"?
> Something that lists the precise contents of each directory, or rather a
> conceptual description of where to find what? Should this be a document of the
> code repository or a description of the homepage?

I was thinking of a high-level description of what should go where (and perhaps
why, i.e., the rationale). Something that could help people decide where to put
things and also help find things and understand the code structure on a high level.

Regarding where/how to document it: don't really know. I'll suggest it for the
next meeting.

I made the change, moving the class SCCs to the subdir algorithms, as the first
representative of such classes. Issue669 will deal with with moving further
algorithms there.

What exactly did you mean by "master documentation on the directory structure"?
Something that lists the precise contents of each directory, or rather a
conceptual description of where to find what? Should this be a document of the
code repository or a description of the homepage?

I'm in favour of an algorithms directory. I 
wouldn't move the RNG there. Do we have a 
master documentation on the directory 
structure somewhere? If not, I think this 
would be good to add.

Florian mentioned a few examples* that could end up in a subdirectory
"algorithms", but we don't have concrete plans for this yet. This algorithm
collection could then contain a CMake plugin for each utility that ends up being
there. I'm not sure if there are that many examples of such algorithms that
grouping them into their own directory would be justified, but maybe it is still
worth starting this now. What do you think? 

Otherwise, I'd leave the files in the main directory and have a separate CMake
plugin for the class (and a namespace, because CMake plugin also means
namespace, if I remember correctly).

*max clique computation of PDBs, Intpacker, maybe RNG which is now part of
"utils" (although I think this would rather be a system utility than an algorithm)

I think we discussed a place for "algorithmic utilities" like these. Perhaps
Florian might know?

I included the scc files, which I think originally stem from Fast Downward's
preprocessor, as a CMake plugin rather than making it part of the core. I don't
know if there is a better place for this class, as it is rather a utility, but
still does not fit the "systems utils" plugin we have.

The code can be found here:
https://bitbucket.org/SilvanS/fd-dev/pull-requests/19/issue667/diff

I'd like to queue this code review into the famous Downward FIFO :-)

We would like to integrate the recent merge strategy based on SCCs of the causal
graph, from the ICAPS 2016 paper An Analysis of Merge Strategies for
Merge-and-Shrink Heuristics.