I'm looking for a quick method/algorithm for finding which nodes in a graph is critical.
For example, in this graph:
Node number 2 and 5 are critical.
My current method is to try removing one non-endpoint node from the graph at a time and then check if the entire network can be reached from all other nodes. This method is obvious not very efficient.
What are a better way?
See biconnected components. Calling them articulation points instead of critical nodes seems to yield better search results.
In any case, the algorithm consists of a simple depth first search where you maintain certain information for each node.
there are several better ways. research is always helpful
but since this is homework, the point of the exercise is likely to be to figure it out yourself
hint: how could you decorate the graph to tell you what nodes depend on what other nodes, and would this information perhaps be useful to spot the critical nodes?
Related
I have undirected, unweighed graph. I have a file that contains list of pairs (connected nodes). Each node may have any number of neighbours. I have to find one or all possible ways to traverse from a specified node to another.
I tried the depth first search - it works pretty well but my friends suggest that it may be pretty slowly. What other algorithms would you suggest? Could you please provide example pseudo code for them?
I got some data set of a graph.
then I have to get distance between city A and B.
How can I know reachability of route from A to B ?
do I have to search for all reachable cities with a*?
I think that needs so much time.
If you want to know if an arbitrary node is reachable from another arbitrary node, then yes, you will need to search the graph. Yes, this means you could end up traversing every node on the graph. Yes, if you have a huge number of nodes, it will be slow. Life is tough.
If you need to do many such reachability checks, it might be worth it to pre-process the graph, and store reachability information which can be used for faster lookups. That information will probably take a lot of space, though you could use secondary storage (i.e. hard drive).
I am looking for an algorithm that will automatically arrange all the nodes in an n-tree so that no nodes overlap, and not too much space is wasted. The user will be able to add nodes at runtime and the tree must auto arrange itself. Also note it is possible that the tree's could get fairly large ( a few thousand nodes ).
The algorithm has to work in real time, meaning the user cannot notice any pausing.
I have tried Google but I haven't found any substantial resources, any help is appreciated!
I took a look at this problem a while back and decided ultimately to change my goals from a Directed acyclic graph (DAG) to a general graph only due to complexities of what I encountered.
That being said, have you looked at the Sugiyama algorithm for graph layout?
If you're not looking to roll your own, I came across yFiles that did the job quite nicely (a bit on the pricy side though, so I did end up doing exactly that - rolling my own).
I am given a network defined by nodes and links. I have to search all loops in the network. No coordinates will be given for the nodes.
Is there any existing algorithm or library that can do this. Or can you please give me some idea how I can approach this problem? I am programming in .NET.
I draw a diagram to illustrate what I need here
Try Distance vector Routing.
This algorithm finds the shortest path to all other nodes in a network from a node.
On the assumption that your edges are not directed and that there is a maximum of one edge between nodes then a http://en.wikipedia.org/wiki/Spanning_tree Depth-first spanning tree will cover all nodes and indicate where the cycles (which is what I think you mean by loops) will occur. We use this algorithm for finding "rings" in chemical structures. There are many implementations in many languages - here's a tutorial with an applet (http://oneweb.utc.edu/~Christopher-Mawata/petersen2/lesson20.htm)
The loops are called cycles, and this answer has a lot of informations for you.
I'm using the Lengauer and Tarjan algorithm with path compression to calculate the dominator tree for a graph where there are millions of nodes. The algorithm is quite complex and I have to admit I haven't taken the time to fully understand it, I'm just using it. Now I have a need to calculate the dominator trees of the direct children of the root node and possibly recurse down the graph to a certain depth repeating this operation. I.e. when I calculate the dominator tree for a child of the root node I want to pretend that the root node has been removed from the graph.
My question is whether there is an efficient solution to this that makes use of immediate dominator information already calculated in the initial dominator tree for the root node? In other words I don't want to start from scratch for each of the children because the whole process is quite time consuming.
Naively it seems it must be possible since there will be plenty of nodes deep down in the graph that have idoms just a little way above them and are unaffected by changes at the top of the graph.
BTW just as aside: it's bizarre that the subject of dominator trees is "owned" by compiler people and there is no mention of it in books on classic graph theory. The application I'm using it for - my FindRoots java heap analyzer - is not related to compiler theory.
Clarification: I'm talking about directed graphs here. The "root" I refer to is actually the node with the greatest reachability. I've updated the text above replacing references to "tree" with "graph". I tend to think of them as trees because the shape is mainly tree-like. The graph is actually of the objects in a java heap and as you can imagine is reasonably hierarchical. I have found the dominator tree useful when doing OOM leak analysis because what you are interested in is "what keeps this object alive?" and the answer ultimately is its dominator. Dominator trees allow you to <ahem> see the wood rather than the trees. But sometimes lots of junk floats to the top of the tree so you have a root with thousands of children directly below it. For such cases I would like to experiment with calculating the dominator trees rooted at each of the direct children (in the original graph) of the root and then maybe go to the next level down and so on. (I'm trying not to worry about the possibility of back links for the time being :)
boost::lengauer_tarjan_dominator_tree_without_dfs might help.
Judging by the lack of comments, I guess there aren't many people on Stackoverflow with the relevent experience to help you. I'm one of those people, but I don't want such an interesting question go down with with a dull thud so I'll try and lend a hand.
My first thought is that if this graph is generated by other compilers would it be worth taking a look at an open-source compiler, like GCC, to see how it solves this problem?
My second thought is that, the main point of your question appears to be avoiding recomputing the result for the root of the tree.
What I would do is create a wrapper around each node that contains the node itself and any pre-computed data associated with that node. A new tree would then be reconstructed from the old tree recursively using these wrapper classes. As you're constructing this tree, you'd start at the root and work your way out to the leaf nodes. For each node, you'd store the result of the computation for all the ancestory thus far. That way, you should only ever have to look at the parent node and the current node data you're processing to compute the value for your new node.
I hope that helps!
Could you elaborate on what sort of graph you're starting with? I don't see how there is any difference between a graph which is a tree, and the dominator tree of that graph. Every node's parent should be its idom, and it would of course be dominated by everything above it in the tree.
I do not fully understand your question, but it seems to me you want to have some incremental update feature. I researched a while ago what algorithms are their but it seemed to me that there's no known way for large graphs to do this quickly (at least from a theoretical standpoint).
You may just search for "incremental updates dominator tree" to find some references.
I guess you are aware the Eclipse Memory Analyzer does use dominator trees, so this topic is not completely "owned" by the compiler community anymore :)