Hello,

This is just a heads up: I created a quick and dirty POC for a sigma.js louvain plugin using your project.

You can view it here: https://gist.github.com/rjbriody/3bf97ea074d20c583c50

And here is the sigma.js discussion: jacomyal/sigma.js#343

Let me know what you think. Maybe you would like to polish the plugin and offer a pull request yourself. Or maybe you want nothing to do w/ it :)

Thanks,
Bob

As said in the title, does this package support nodes with assigned "x" and "y" positions?

Is it possible to pass an argument (or otherwise alter the code) such that a user can control the sensitivity of community detection (i.e. more sensitive would result in a larger number of communities and less sensitive would result in a smaller number)?

I see in the original paper the following: "However, our algorithm provides a decomposition of the network into communities for different levels of organization..... This result suggests that the intermediate solutions found by our algorithm may also be meaningful and that the uncovered hierarchical structure may allow the end-user to zoom in the network and to observe its structure with the desired resolution."

I am not clear though how I can obtain that flexibility / sensitivity. Thanks.

jLouvain crashes whenever a node is called 'constructor', apparently it overrides some object's native constructor property.

Similar crash may occur whenever other javascript resssserved words are used as node names.

Prefixing nodes names (e.g. like in d3js' .data) should solve this problem.

Hi,

Would you consider making this library compatible with node.js?

Happy to send a pull request if you are interested.

Description

Since jLouvain is not using an immutable datastructure it is possible that the data provided during initialization (nodes and edges) will be different when calculating the community.

How to reproduce

This behavior can be seen in the provided example/example.html
The prepared community on line 298 var community = jLouvain().nodes(node_data).edges(edge_data); will be calculated in the on-click handler defined in line 367. This will happen AFTER d3 used the data to display the graph and AFTER d3 modified edge_data

Moving line 364 var community_assignment_result = community(); up to line 299 will result in different communities:

Reason

The library d3 is changing the value inside edge_data from {source : 1 ..} to {source: {key: "1", value: 1, index: 1 ...}}. Therefore using edge.source will result in unexpected behavior. Especially using partition[edge.source] will return undefined.

Is there any data coming in that can tell about the sparsity of the resulting graph — e.g. if there are many disconnected communities or if one community has disproportionally more nodes than the others? I remember in the original algorithm there was this number 0.4 that if it was higher than the communities detected were distinct enough, and if it was less, then not so. Anything similar can be derived from this algorithm and if not, where would I start looking in the code itself?