0

Graph drawing algorithms, such as those described here, check all the vertices two-by-two and apply additional forces if two vertices are connected by an edge. If we have a very large graph, checking all pairs of vertices would be costly. Is there any graph drawing algorithm that draws a large graph using only existing edges, not by verifying all possible pairs?

EDIT
By drawing algorithm, I meant an algorithm that assigns a 2D or 3D position to each vertex such that rendering spheres or circles (or any other shape) as vertices at their assigned positions lead to a plausible visual representation of the whole graph.

Community
  • 1
  • 1
Farzad
  • 3,288
  • 2
  • 29
  • 53
  • does the graph have to be planar? – Tomas Jan 11 '14 at 13:43
  • The problem with your question is in very unclear requirements on the drawing algorithm - *"plausible visual representation"* is not a clear objective criteria. I can easily create a very simple drawing algorithm for you, that will fulfill the condition but it will create ugly graphs. Who will decide what is ugly and what is not? – Tomas Jan 11 '14 at 17:44
  • I had been thinking there must be an algorithm out there in the literature that satisfies mentioned conditions. – Farzad Jan 11 '14 at 18:33
  • Which conditions? You have specified no clear conditions. Go back and read my previous comment again. – Tomas Jan 11 '14 at 18:56
  • Conditions on the way the algorithm performs the drawing. I'm looking for a previously proposed algorithm that doesn't have to perform 2-by-2 computation on all vertices in the graph. – Farzad Jan 11 '14 at 19:03
  • OK, then just assign coordinates [0, 0] to each vertex. That's a drawing algorithm that goes with your conditions. – Tomas Jan 11 '14 at 19:15
  • See the link in the answer for description. This explains what I wanted. I'm sorry if I couldn't convey properly the idea in my mind. – Farzad Jan 15 '14 at 04:06

2 Answers2

0

If you have sparse matrix you can consider about creating graph as list of neighbours or simplier like pair of vertices (e.g. (1, 3) and 1 and 3 are the numbers of vertices).

upstreamfall
  • 44
  • 3
  • Having the list of edges is a representation and storing format not a graph drawing format. I edit the question and add this. – Farzad Jan 08 '14 at 17:21
0

Check this Spring-Electrical Embedding It is in O(nlog n).

Peng Zhang
  • 3,475
  • 4
  • 33
  • 41
  • Thanks. That's what I had been thinking as a solution: confining the attractive force to nearby vertices. I think it adds the overhead of *knowing* neighbors but it's not something that cannot be solved. – Farzad Jan 15 '14 at 04:03
  • Peng, what is `n`? You should always say what is `n` if you put expression like that. Right @Farzad? – Tomas Jan 15 '14 at 10:20
  • @Tomas, n is the number of nodes in the graph. This is the common notation from graph theory. :-) – Peng Zhang Jan 15 '14 at 11:23
  • Well, then it's clearly false, because number of edges can be up to n(n-1)/2. How do you want to draw `O(n^2)` edges in `O(n log n)` time? – Tomas Jan 15 '14 at 12:48
  • 1
    And by the way, answers like this are discouraged, because they don't contain anything besides the link - which might stop working. – Tomas Jan 15 '14 at 12:51
  • 2
    @Tomas what you're referring to is the worst case that doesn't happen for real-world large graphs. Have a look at [SNAP large graph dataset](http://snap.stanford.edu/data/). These large graphs are sparse, they may have millions of vertices but don't have hundreds of billions of edges. Plus this post has the answer I was looking for. A useful link is better than a long useless answer or no answer. – Farzad Jan 15 '14 at 17:38