Add Louvain community detection algorithm

[Becheler]

Implement #447

• Multi-level modularity optimization following Blondel et al (2008)
• Supports custom quality functions (other than modularity) with policy-based design (extensions to come to propose alternative quality functions to match gen-louvain)
• Incremental quality tracking
• Lazy rollback
• Vertex shuffling
• Competitive with established implementations (I will work on making the benchmarks reproducible)

But:

• documentation is not ready
• example is not ready
• just realized I forgot to test with different graph types + boost concepts

[jeremy-murphy]

Not sure why this error is occurring only for OSX 11.7 C++14. I assume this is not specific to your code.

In file included from ../../../boost/container/detail/operator_new_helpers.hpp:26:
../../../boost/container/detail/aligned_allocation.hpp:87:26: error: no member named 'aligned_alloc' in the global namespace; did you mean 'aligned_allocate'?
   return rounded_size ? ::aligned_alloc(al, rounded_size) : 0;
                         ^~~~~~~~~~~~~~~
                         aligned_allocate
../../../boost/container/detail/aligned_allocation.hpp:77:14: note: 'aligned_allocate' declared here
inline void* aligned_allocate(std::size_t al, std::size_t sz)
             ^
1 error generated.

[jeremy-murphy]

Just a few comments, more later.

[jeremy-murphy]

I know embedded revision histories were a thing in the past, but I would prefer to keep all this metadata in git.

[Becheler]

I did not like it either, I'm glad you don't ahah :)

[jeremy-murphy]

We generally try to avoid hard-coding the choice of data structure, especially std::map and std::set, so instead of templating VertexDescriptor and WeightType we should template the whole map type, so users can use boost::unordered_map or some other kind of property map of their own choice.

[Becheler]

Mhhh I see. I felt it was not in the BGL spirit to do so, and Joaquin also mentioned it, but I was not sure how to solve it without making the API heavy. Can we default to a concrete type to simplify user's experience ? Also, is it ok to use boost::unordered_map if it adds the constraint of key_type being hashable ? That was my idea behind using std::map

[jeremy-murphy]

These should almost certainly be input parameters taken by non-const reference so that the user a) decides their type and b) automatically gets their value at the end.

[Becheler]

So they gain access to the whole hierarchy. Ufff it's a lot of guts leaking out haha
Will do, and tell you in case of problemsm thanks again for your time !