Collect generic algorithm classes in their own subdirectory called
algorithms.
Suggested algorithms to be moved into the mentioned folders are:
- dynamic_bitset
- int_packer
- max_cliques
- priority_queue
- segmented_vector
- equivalence_relation

Perfect. I merged and pushed the branch. Thanks for your work!

Yes I have implemented the suggested changes and tested the dependencies.

What's the status here? Are you finished with Florian's comments, Daniel? If so, I 
will merge the branch.

Thanks. I left a few comments on Bitbucket but nothing major. I found some of
the old forward declarations but I'm not sure if I got them all. Maybe a search
for "class IntPacker;" would be good (and for the other moved classes as well).

@Florian
I have prepared the branch as you have suggested: 
https://bitbucket.org/danielkillenberger/fast-
downward/branch/issue669_default_comparison

Note that the changes are backwards as I have replaced the new files in branch 
'issue669' with the original files from 'default' in the algorithms folder. I have 
renamed priority_queue.h to priority_queues.h to make a direct comparison on 
bitbucket possible.

I can have a look after the Easter break.Could you try to make the diff easier
to review with a temporary branch? Bitbucket unfortunately is bad at recognizing
moved files.

One thing that could work is to create a temporary branch based on the same
master revision where the issue branch splits off. In the temporary branch, copy
(with "hg copy") the old files to their new location. In Bitbucket, we would
then look at the diff between the temporary branch and the issue branch. But
that might not work, so maybe do a small trial run with one file first.

If that doesn't work, then you could branch the temporary branch off of the
issue branch tip, copy ("hg copy") the new files to their old locations, commit,
do a regular file copy from the original files from the master over the files in
the repo, and commit again. The diff between the issue branch and the temporary
branch should again show the actual file changes this way.

In both cases, please remember not to push the temporary branch into the main
repo during the merge.

Daniel has moved all files listed in the summary and the code looks good to me. 
 Another pair of eyes probably won't hurt though. Silvan or Florian, could you have 
a look at the pull request, please?

I like your idea and I think it fits our conventions. We have 
cegar/subtask_generators.h, merge_and_shrink/types.h, pdbs/types.h, 
utils/collections.hm globals.h, options/registries.h, options/predefinitions.h, 
options/errors.h, etc.

Would calling the namespace and file "priority_queues" (plural) be consistent
with our conventions? Unlike other source files like dynamic_bitset, it contains
multiple related priority queue classes if I recall correctly, so it might fit.

We are putting each of the algorithms into its own CMake plugin and namespace. For 
priority_queue.h this is not straightforward since the "priority_queue" name 
collides with std::priority_queue and we usually do "using namespace std;". Do you 
have a good idea how to solve this?

EquivalenceRelation fits the bill.

BTW, looking at the code for EquivalenceRelation, the header file contains an
unrelated and unused structure DoubleEpsilonEquality, which should be removed.

(Addendum: I've just removed the dead code.)

@Malte: what about EquivalenceRelation?

@silvan Thanks!
I think Jendrik was able to give access to the entire AI Group.
I set the status of the issue back to 'in-progress' as only a part of the issue has 
been resolved.

Collected the suggested algorithms that are to be stored in the algorithms/ dir in the 
issue summary.

Yes, the dynamic bitset would also fit well.

Should we also move "utils/dynamic_bitset.h" into the "algorithms" directory?

The aibasel group should now have access to Daniel's repo.

I think priority_queue.h would fit well into the algorithms directory.
I'd also suggest segmented_vector.h.

Can you collect these suggestions, including the earlier ones, in the "optional
summary" field? Then we won't need to scan over the old comments later on.

@Daniel: It's probably easiest if you make me an administrator. Then I can give 
access to the aibasel group.

@Silvan: We're trying not to do too many steps at once for the first issue. Once 
everybody is happy with the changes to IntPacker, we'll move other algorithms.

@All: Are there other algorithms we should move to the "algorithms" directory? 
Maybe priority_queue.h?

Welcome on the issue tracker, Daniel!

I cannot access your repository. Can you give access to SilvanS (and/or others
on this issue, e.g. jendrikseipp or florianpommerening)? Furthermore, the change
you suggest would only be a part of this issue, i.e. if you wanted to apply a
patch for this issue, it should contain all the changes mentioned in the comment
below (msg5591).

Move intPacker to algorithms/ and give it its own namespace

https://bitbucket.org/danielkillenberger/fast-downward/pull-requests/2/issue669/diff

In issue667, we will add a class to compute maximal strongly connected
components of a graph, given in a generic "list of neighbors" form. We would
like to collect such generic algorithm classes in their own subdirectory called
algorithms. For the moment, at least the maximal cliques computation from the
pdbs subdir and the Intpacker class could also belong to that set of algorithm
classes.