Message Boards Message Boards

GROUPS:

Wolfram has abandoned the Graphs and Networks functionality (??)

Posted 4 months ago
1594 Views
|
18 Replies
|
121 Total Likes
|

This is a cautionary tale for those who choose Mathematica as the main tool for their work.

It is now clear to me that Wolfram has simply abandoned the Graphs and Networks functionality area and I am left high and dry. I have no recourse because Mathematica is closed source so there is only so much a user can do to fix or work around problems. Reporting bugs in this particular area has now clearly proven to be useless. Most simply do not get fixed, no matter how serious they are, or how great a hindrance they are to practical use. No new functionality has been added since version 10.0. My colleagues who use other tools (mostly Python and R packages) are more productive at this point, but I have a handicap with those systems because I made the mistake of investing most of my time into Mathematica, and stayed optimistic about it even in the face of the most obvious warning signs.

I am writing this post because those people who have not heavily invested in Mathematica, and in particular this functionality area of Mathematica, are not in a position to see this and may fall in the same trap I did. What if the same thing happens to the functionality area that is critical to your work?

Wolfram Research, of course, will not tell you that they gave up on Graph. Thus, after my experience, I think I owe it to the community to warn you about the situation.


Some might ask me what specifically is wrong. I have made many posts on this forum about Graph-bugs (you only have to search), and I reported many more to WRI. There is always a last straw—it would be pointless to show it. Those who know me will know that I am not writing this admittedly emotional post out of ill will towards WRI. I have betted on Mathematica more than most, and have been advocating for it throughout the years. I even have a network analysis package with ~250 functions. If I am forced to abandon Mathematica for this type of work, then the countless hours that went into this package will all have been in vain.

I admit that I am writing this public post partly out of desperation to try to get WRI to either fix the many serious Graph-problems, or otherwise publicly state that Graph is now abandoned so those of us who have been using it can stop wasting our time.

18 Replies

Hi Szabolcs,

My voting routine still uses the original Combinatorica package by Sriram V. Pemmaraju and Steven S. Skiena. This uses a somewhat other format, and I did not want to get lost in brackets. It is still included in Mathematica. If I recall it correctly, Mathematica's graphs & networks have been based upon Combinatorica, which might explain that WRI hasn't its heart on the issue as you suggest or show. I am not in graphs & networks as a topic myself, only such a user. I can only hope for you that there is such a community that would support you on this issue.

You might like my earler text "Beating the software jungle", now included here: https://zenodo.org/record/291974

Best regards, Thomas

I find it odd the lack of evolution (or basic maintenance) of this functionality, as graphs seem to be used more and more in other fields being integrated in the WL. But I guess that the functionality is probably good enough for these applications (that are basically representation related?).

I think that I would also have fallen on your problem, as graphs functionality focus was considerable when it was presented (and I have the sensation that it never really stopped), with multiple blog posts talking of it. I even remembered a post on Spacetime that seemed to point to the need of considerable graph capabilities.

(for version 12, at the 30th anniversary, I would be very happy with just functionality polishing)

I cannot not agree with you more. They should release 12 with all the bugs sorted (i mean all open issues on StackExchange) and should add more functionality for Graphs, ImageProcessing and ComputerVision. That would be a considerable considerable improvement.

Posted 4 months ago

Here are the at present 24 unresolved bugs I got via a quick-and-dirty query of the StackExchange API:

Some of these are rather inconsequential (but annoying), e.g. Graph3D - Double Arrow in 3rd Dimension, but some are absolutely fundamental and absolutely need to be fixed, e.g. GraphDistance gives incorrect result in weighted multigraph or Why equivalent Graph objects yield different results?

And keep in mind this list is just those left open, which is a fraction of the total number reported by Szabolcs (and possibly only partially fixed).

Most of the issues cited here aren't in my area, and I'm not qualified to comment on them. But one is...the bug in export of BezierCurve to PDF. I can reproduce the problem in versions 10.0 to 11.1, but as of 11.2, it looks like that problem is resolved. I just added a comment to the SE post saying the same thing.

Some of the biggest hindrances are bugs that are in fundamental functionality and impact almost every network analysis workflow.

For example, using VertexAdd/VertexDelete/EdgeAdd/EdgeDelete is like walking on eggshells. Unless one is extremely careful, they will silently break something in the internal representation of the graph and will prevent other functions from working several steps later. (This typically happens when properties are present.)

There are also instances of problems which have been reported as far back as v9, but are claimed not to be bugs, despite making practical work very inconvenient. For example, this takes ~30 seconds:

g = GridGraph[{50, 50, 50}];
NeighborhoodGraph[g, 123]; // AbsoluteTiming

This is equivalent, and it is instantaneous, as it should be:

AdjacencyList[g, 123]; // AbsoluteTiming

{0.000173, Null}

Subgraph[g, Append[AdjacencyList[g, 123], 123]]; // AbsoluteTiming

{0.000675, Null}

Why is NeighborhoodGraph so slow then? I cannot understand how this is not considered a bug.

Another example is Graph[KaryTree[5], VertexStyle -> Blue], which mysteriously doesn't evaluate. There's something wrong with the output of KaryTree. This works with almost any other graph. When I originally reported it, I was told that this is not a documented syntax of Graph, so not a bug. I had to point out that if I use Graph3D (explicitly used on graphs in the documentation) instead of Graph then the same thing happens ...

But the point is what makes practical work easy and possible and what makes it painful, not the precise phrasing in the documentation. Imagine working on a deadline and hitting these sorts of problems one after the other, always having to stop, backtrack, and find out what exactly went wrong.

Yet another practical hindrance is the bad state of import/export formats. When doing network analysis, it is important to have an exchange format that can encode edge and vertex properties. The two common formats that are also supported by Mathematica are GML and GraphML. Trying to export an edge-weighted graph to GML results in a flood of error messages. Edge weights are the single most commonly used property ... As for GraphML, its implementation is not standards compliant, so most other programs won't read files written by Mathematica (even if they would, properties are written in Wolfram Language syntax, and would need to be parsed... other programs won't understand 3.14` with the backtick at the end). Also, reading GraphML is very slow, and not feasible for as few as a few thousand vertices. All this means that I must always resort to workarounds like storing a single graph in multiple CSV files (not a graph specific format, so often a single file is not sufficient for one graph).

I think what is really missing, in addition to resuming development of this functionality area, is for developers to actually observe how people would want or need to use the system. See how people do network analysis in Python or R with packages like networkx or igraph. Is it possible to do the same task in Mathematica? Usually, it's painful, and it's not even because some graph algorithm is missing or buggy, but because the very basics are broken: import/export, data cleanup, property handling, trivial graph manipulations such adding or removing edges/vertices. Very basic operations such as directed/undirected conversion, reversing edges, taking subgraphs, etc. become unreasonably difficult for edge-weighted graphs, not to mention other stored properties. There isn't even a good way to check if a graph is edge weighted (!!) or quickly remove edge weights from a graph. These sorts of things are what take up the bulk of the time in everyday work.

Yet another complaint I have is that even though a lot of work went into implementing certain functions, they are not properly documented and therefore practically useless. Consider FindGraphCommunities. Community finding is not a mathematically well-defined problem. What the function does is basically defined by the algorithm it is using—but this is not documented at all. Results obtained with this function are unpublishable because we literally don't know how the function works. A few references and better documentation could go a long way. Compare functions like Integrate, which don't have this problem: I do not need to know how Integrate works to understand what an integral is, or to be able to verify that the result is correct. I do need to know how FindGraphCommunities works to be able to make any use of it.

The situation is disappointing because otherwise Mathematica contains a very competitive set of network analysis functions. Until recently it was not easy to find all these integrated into the same system. If the reason why development stopped is that people were not using Mathematica to work with networks, that's misguided. If people don't use it, it's because of the problems I described above, all of which are fixable with much less effort than what was required to develop Graph in the first place.

Finally, one of the biggest practical problems is that property handling for multigraphs is completely broken due to a fundamental design problem: edges are identified by their end vertices, which makes parallel edges indistinguishable. This is of course not going to be easy to fix.

It would be unfair if I did not mention that today I learned that two bugs of the type I describe above were fixed in 11.3.0, showing that this area does receive some relevant fixes.

Namely, EdgeAdd now works with certain graphs it used to fail with: EdgeAdd[RandomGraph[{2, 0}], {1 <-> 2}], and HighlightGraph now works on graphs whose vertex names are lists: HighlightGraph[Graph[{{1, 2} <-> {5, 6}}], {{1, 2}}]. Both of these failed in 11.2, and I am very happy about both fixes.

I still believe that the rate of fixes in this functionality area is lower than in other parts of Mathematica (and that it is not just my subjective impression that this is the case). I am hoping that in the future graphs will receive the same attention they did around version 10.0.

I am a user of the built-in Graph functionality (not a heavy user) but i am seriously concerned after what you have mentioned in your post. WRI has to fix the past bugs and catch up with R and python when it comes to Graphs

Posted 4 months ago

I even started with Mathematica just because the graph functionality. I'm not a very heavy user with special demands but Szabolcs work helped me out very often. I thinks graphs are a fundamental need in such frameworks and I have hope that wri will address the issues. We'll see but some support statements from wri would help.

Posted 4 months ago

One point of concern is that over the entire set of those Live CEOing videos I’ve never seen one on Graph (although I haven’t seen every single one—just many). This suggests there might not be interest in this high up at WRI.

The closest I've seen was on Tree Structures https://www.twitch.tv/videos/228665929

i've been kicked off the forums before for making such a post as the original. Good luck!

Mathematica does try to "stay compatible" in my view - but they "dissed" PostScript for GL graphics and version 5, 6 took on a view of breaking scripts (.nb) HOWEVER afterward (perhaps they did some employee changing) they reverted to being very compatible (fewer broken scripts).

I do prefer ".m" releases (noting sometimes they've released ".m" after dis-continuing a library in the past).

I do agree they should better protect scripts to "not break". But I don't agree they are getting worse - at this time, yet.

Wolfram has most definitely not abandoned Graphs & Networks functionality. It is true that all projects at Wolfram go through periods of different intensity of development and the most intense development phase for Graphs & Networks certainly spanned Version 8, 9 and 10. Currently there is a lot of functionality being added and planned, with a focus on several vertical functionalities such as neural networks, chemistry, general trees and geometry. In fact, graphs and networks are being deeply integrated into areas which stress them in new and interesting ways.

The functionality is also being maintained. Here are some recent bug fix statistics: WL 10.0 - 62, WL 11.0 - 27, WL 11.3 - 97. As of today, the number of open bugs is 208. We will have another major batch of bugs fixed in the coming release. Interestingly we find that 70-90% of the bugs we track, are found internally. Of the 24 issues published in an earlier post, the following 5 are fixed in 11.3:

And many more issues are already fixed in our development version.

Functions such as NeighborhoodGraph, preserve the layout of the input graph. This can be computationally expensive for a large GridGraph[{50,50,50}] with 125 000 vertices and 367 500 edges. Here is a workaround if performance is the primary goal.

g = GridGraph[{50, 50, 50}];
NeighborhoodGraph[g, 123,  GraphLayout -> None]

Informations about algorithms are provided to users through Wolfram Technical Support or in public forum such as Wolfram Community.

We are looking forward to dramatic expansions in Graphs & Networks functionality. We are even more excited about its many applications across different domains and the graph related functions in the pipeline. This is a very strong framework that will continue to evolve quite a bit and it is getting integrated in so much functionality that we are starting to take it for granted and becomes part of the everyday fabric of the system.

Dear @Charles,

Personally, I'd prefer if the flaws in existing capabilities were fixed before adding more and more syntax sugar and interconnectivity with some fancy neural-something glitter. Graph's Property interface is immensely broken by design (everything breaks when a list is used as a vertex) and if one is looking for performant routines for dealing with graphs, the first places to look are?SparseArray`* and Needs["IGraphM`"]---and not ?Graph or ?GraphComputation`*.

When I need a very specialized routine for a localized task, then I am okay with writing it by myself. But I have to rely on basic things working correctly and efficiently. At the end of the day, people need their job done with the software. But too many of my days end with only an ad-hoc workaround for some fundamental but broken functionality that has be around already for many years. The marketing stuff is completely irrelevant for long-term users.

Let me add that I interpret Szabolcs' criticism to be firstly and foremostly aimed towards the overall development strategy at Wolfram Research; not towards the individuals working there (who do a very good job as far I can tell).

Whenever I can, I advocate for using Mathematica and I am convinced that the core language is great and lets me do whatever I want (or at least whatever I need) within very short time. Please, please with sugar on top: Don't prove me wrong.

Posted 4 months ago

Hi Charles, Thx for your reply. Looking at the StackExchange issues logged there are some that seem more fundamental. Anyway I really appreciate your reply to give feedback on this subject. I agree that Graphs are seen as a fundamental part in the Wolfram system. What I would like and propose is that the dramatic expansions in the Graphs and Networks functionality as you mentioned might be shown in a Wolfram Twitch session. This way feedback can also be given directly. Thx for time to reply.

I second this suggestion: I would very much like to see a Twitch session on graphs.

On the StackExchange issues: I should note that they do not represent my experience very well. Excepting my SE posts in the last couple of days, I do not generally post on SE about bugs I find, as I do not personally believe that SE can or should be used as a bug repository. Instead, I report them to Wolfram Support directly, without leaving any pubic record. (Of course, if I need help from the community to work around a problem, then I do ask publicly.)

Posted 4 months ago

Dear @Charles,

Thank you for the encouraging response. I do believe that Mathematica has tremendous potential in these areas, and I am glad to hear that there are plans to realize that potential.

As for NeighborhoodGraph, now I understand what you mean: it preserves the vertex coordinates of the original graph, thus it must run a layout algorithm on the original.

May I suggest to also allow development to be driven by user needs, rather than only internal needs? The reality of the situation is that Mathematica is still painful to use for non-trivial network analysis tasks.

One of the pain points is property handling. It would be useful to make improvements here based on what people actually need for practical work, starting with weighted graphs (the most common property). A while ago I submitted a 9-point list of basic tasks that come up very frequently when working with weighted graphs, and cannot currently be done with Mathematica (or at least not easily, or not with satisfactory performance).

Finally, do you have plans to address the incompatibility between multigraphs and edge properties? I understand that this is not at all easy, and requires some level of re-design. However, it is quite critical for practical network analysis, and even for some graph theory (= pure math) applications. The basic issue is that edges are referred to through their endpoint vertices, thus parallel edges are not distinguishable. Some packages (like igraph) use edge indices to refer to edges. This is sometimes possible in Mathematica (e.g. for those properties that are stored as a vector, though using the vector syntax is buggy sometimes), but generally it does not seem to be compatible with the design of Graph. Other packages, like nertworkx, use an additional "key" to distinguish parallel edges. This seems like a not very pretty, but workable solution to the problem.

Posted 3 months ago

@Charles Pooh:

Informations about algorithms are provided to users through Wolfram Technical Support or in public forum such as Wolfram Community.

Sometimes I find it a bit difficult to get information on methods and algorithms this way. Just now my request (through Support) for a reference to the method that GraphLayout -> "PlanarEmbedding" uses was refused. Thus I thought I would ask here, publicly (as you basically suggested):

Drawing a planar graph with straight edges and without edge crossings is a non-trivial problem. Since 1990, several algorithms have been published for constructing such drawings on integer grids. However, most of them do not produce a "nice" layout that is easy to interpret for humans. They often contain very small angles between edges or vertices so close to an edge that visually they overlap. I have been experimenting with using these algorithms (including Mathematica's) in more complicated practical schemes to produce more useful drawings. I want these schemes to be reproducible without Mathematica. Thus: which method does "PlanarEmbedding" implement? Can you give me a reference?


Another instance where I was unable to get information is the method used for random sampling from a "DegreeGraphDistribution". The usual method for sampling graphs with a given degree distribution fall into two categories: 1. Direct construction (such as the configuration model), which samples exactly uniformly 2. Markov chain based methods that repeatedly modify the graph (randomly), but only sample approximately uniformly (furthermore, the mixing times are usually unknown).

Clearly, knowing at least whether the sampling is exactly uniform is important for some applications. I asked W Support in 2012 (TS 44838) what sampling method is being used, and I was told that it is the configuration model. However, by experience, sampling is not exactly uniform (with the configuration model it should be): https://mathematica.stackexchange.com/q/167450/12

Thus, once again, I would like to know what method is being used for sampling from a DegreeGraphDistribution. I was not yet able to get a response about this (CASE:4027392).

I should also note that the documentation of DegreeGraphDistribution is in need of some expansion. I was unable to find any explicit statement about whether it represents a uniform distribution over the set of graphs with the given degree sequence ("degree graph distribution" is not a term used anywhere else than in the M Documentation, so it is of no help). Also, by experience, the distribution that RandomGraph[DegreeGraphDistribution[...]] samples from is not at all uniform if the degree sequence cannot be realized by a simple graph (which is actually expected from the configuration model—but the documentation never mentioned the configuration model). Without knowing the distribution it represents, this symbol is not very useful.

Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract