If I didn't want to use Mathematica to work with networks, I wouldn't be complaining ... I would just jump ship.
There is, of course, a lot of value in Mathematica. I think that Mathematica really is a much better integrated system than what you might find elsewhere. This is not just marketing. Most functions will easily work together, even if they are from very different application areas. Working with networks usually involves a lot more than just manipulating Graph
expressions. I might also want to do statistics on their features, visualize results, do linear algebra on graph matrices, convert between images / meshes / graphs, encode graph problems into ILP or SAT and solve them, etc. Having all these functions work well and easily together has great value in it.
Also, the Graphs & Networks functionality is broad, with lots of graph algorithms implemented. There is huge potential here. This is precisely why the problems I described above are so frustrating. Unfortunately, I still have the impression that Graph
doesn't get as much attention as other functionality areas in Mathematica, and that practical user needs do not always seem to be taken into account.
Regarding the black box functions, we all know that this is one of the major criticisms of Mathematica, but I think that the criticism doesn't apply in every case. There was a question on StackExchange recently, asking whether FindIndependentEdgeSet
uses the blossom algorithm. Of course, it would be nice to know what it uses, but I don't really need to know that in order to be able to use the function. The mathematical problem that the function solves ([graph matching](https://en.wikipedia.org/wiki/Matching_(graph_theory))) is clearly defined without reference to any algorithm. The solutions it returns are easily verified without knowing how they were obtained.
FindGraphCommunities
is different. It is not very useful without knowing how it worksbecause "how it does it" defined "what it does" (more or less). What the function does is only described in an intuitive way, not in a precise way.
Actually, I have alternatives both for DegreeGraphDistribution
and FindGraphCommunities
in IGraph/M (based on igraph). The other day I was working with a network where FindGraphCommunities
returned results that intuitively seemed more reasonable than what I could get with igraph. I would like to use these results. But in this case I can't because I don't know what the function does to formalize the intuitive concept of "communities".
(For those who want to nitpick, I know that I can compute the modularity score of a result, and use it to evaluate how good it is, regardless of how it was obtained. But modularity is not the end of the story when it comes to community detection ... and the documentation doesn't even claim that all FindGraphCommunities tries to do is maximize modularity.)
Actually, looking at the names of the available methods lets me make guesses about what each of them does ... but when I try to verify those guesses, then small things don't match up. How can I even verify the guesses without re-implementing the whole method? If I do, then what would be the point of using Mathematica?
This is why the lack of responses from the developers is so frustrating. It would take so little to make this function useful, but we are denied this, for no apparent reason.
Not everything in Mathematica is like this. Look at the old graph drawing tutorial (written by Yifan Hu perhaps?) It has references to the papers describing the algorithms that it implements (at least the original versions of these algorithms). Why couldn't this be done for FindGraphCommunities
?
Newly added graph drawing methods, like "GravityEmbedding", have no such information. I asked support how "GravityEmbedding" worked (and what it's "RootVertex" suboption does) and received no clear response. Of course, for graph drawing, knowing the method is not critical ... but it's still very useful. What I do not understand is why would the response be denied? It's a newly implemented method (new in M12.0), so the developer who created it must still be around and could answer ... all it would take is to send a link to the paper describing the method. I assume there is a paper because during the Twitch stream (live-streamed meeting) it was mentioned that this graph layout was added based on a user request. It couldn't have been requested unless it was a published method.
Denying the response just leaves a bad taste, and diminishes my confidence in both the system and WRI.
Another symptom of such problems is that "GravityEmbedding"
is designed in such a way that it gets in my way: it doesn't only change the layout, but also changes the EdgeShapeFunction
, as if it weren't just a vertex layout, but a PlotTheme
or GraphStyle
... It was claimed that this is so that it would return a "nice" and immediately usable result, but in fact it does exactly the opposite: it forces me to spend extra time and effort to set the edge shape back to something that looks similar to the default. That takes a lot more effort than you'd expect because the possible settings for EdgeShapeFunction
are not properly documented (same problem again) ... and I still don't know what the correct setting is to get the default.
I remember that during the Twitch stream even Stephen Wolfram asked why GravityEbedding changes the edge shapes (and no convincing response was given), so I'm not the only one who thinks that this is not reasonable.
The example of GravityEmbedding illustrates well a disconnect with actual user needs, and a lack of willingness to communicate with the users of the product.