I want to find K farthest points from a given vertex in a jung implementation of directed graph.
I assume that BFSDistanceLabeler does the job. However, it doesn't provide api for returning K farthest points, so I'll have to do it manually by traversing all vertices in graph and calling getDistance method. Or is there a better way?
But there is a bigger challenge for me. Despite the fact the graph is directed, I want to treat it as undirected for the distance labeler. Is it possible to somehow switch fast from from directed graph to its undirected version?
Why do I need to treat graph as undirected?
I analyze a very large network (milions of vertices) in consequent steps. In every step a small part of network (thousands of vertices) is loaded into a graph and analysed. This analysis requires directed graph and provides result for a one specific vertex which has to be located in the center of loaded area.
When I move from step A to step B, I could delete the whole previous graph and create a new one. Nevertheless, this would be very time consuming. Because I know my new vertex of interest is near to the previous one, a big part of graph can be reused.
And that is why I need to remove K farthest vertices for the new main vertex and replace them with new vertices from surrounding of this vertex.
Lets take a look at bottom picture with graph and lets say that vertex 1 is our vertex of interest. Since the graph is directed vertex number 6 is farthest. However, if graph was treated as undirected, then vertex number 4 would be the farthest and that is what i need.
There is not going to be an asymptotically faster way to find all the farthest vertices from a given input vertex than finding the distances to all vertices.
You can get the farthest vertices more efficiently by calling getVerticesInOrderVisited(), and then traversing the list in reverse order starting from the 'tail': this list should be populated in increasing order of distance from the root (set), so just get vertices from the list until the distance for each one starts decreasing.
(Note: this will not pick up the vertices that may be completely disconnected from the root vertex, which you may consider to be the "farthest"; getUnvisitedVertices() will do that.)
To answer your second question*: essentially what you want to do is to treat the directed edges as undirected. JUNG allows you to do this; instead of using getSuccessors()/getPredecessors(), you can call getNeighbors(), for instance.
As you've inferred, BFSDistanceLabeler doesn't do this; it wants to respect the edge direction if it exists, so it uses getSuccessors().
So here are some options:
Use jung.algorithms.transformation.DirectionTransformer.toUndirected(). This is very easy, but involves creating a bunch of new (undirected) edges
Create a subclass of BFSDistanceLabeler that overrides labelDistances(), and replaces getSuccessors() with getNeighbors(). This is pretty easy, if not very elegant.
Create a GraphDecorator subclass that overrides getSuccessors() to call getNeighbors() on its delegate graph. Then create an instance of your subclass where your original graph is the delegate.
This is the most elegant and general solution. (And at some point it may be useful for us to provide utilities that do this for you; please feel free to file an issue on the JUNG GitHub page: https://github.com/jrtom/jung/issues)
Hope this helps.
*For future reference, please split unrelated questions into separate StackOverflow questions; it makes them easier to answer and to find.
Related
Background for the question:
At the start of every new year at my daughters school the principal always talks about how difficult it is to divide the kids into classes because they have many requests as to who they want to be in class with, and the kindergarden also has some recommendations.
In my mind that is just a weighted, cyclic graph with kids as nodes and requests/recommendations as edges that needs to be split.
The question:
Imagine if you will, a graph with cycles and weighted edges, possibly disconnected.
I would like to divide that graph into n smaller graphs with at least s nodes in each and at most t nodes in each graph while breaking as few edges as possible.
I assume it is NP hard to solve, so it might be an optimization problem really.
Does this graph algorithm have name?
Are there any java libraries that can help me solve this?
Thanks,
Jesper
A component of a graph is also a graph. Last year i had to write code for image stitching which made use of directed graph datastructure which had 64000 pixels and it was not slow at all.
The resulting image is the last one and code is here github.
Well, in your case you can create a graph datastructur. Create a one dimensional array of Linkedlist and within that linklist save the datastructure connected with three arguments, first one is your first one student, second one is student to which the first one is connected and third one is number which expresses strength bound between them.: Example student 1 is connected to student 5 with strength == 100 then it you create a new node Connected c = new connected(1,5,100); and add it to first entry of array like this: array[i].add(c) where i == 1.
Search:Which student is connected to which one: When you try to find which student is connect to which one then you simple go that array index like:
`for(Connected c : array[i].get();
int firstStudent = c.getFirst()
int secondStudent = c.getSecond()
int strength = c.getStrength();`
Your linked list should have an iterator so that you can travers.
This is what it actually looks like:
This problem sounds like a minimum cut problem but for directed graph.
In graph theory, a minimum cut of a graph is a cut (a partition of the
vertices of a graph into two disjoint subsets that are joined by at
least one edge) that is minimal in some sense. wiki
One not optimized solution for the problem you described is to find all connected components and find the minimum cut for each (which result in breaking them) until all resulting components satisfy your criteria.
Now the issue with this method is that algorithms I know for minimum cut work for undirected graphs. In my search on the topic I found an article for this problem which might be of use.
I had a requirement to generate shortest route. The first solution which suited my requirement was Dijkstra's algorithm, and hence I implemented the same (Java). Later, I had to modify the implementation to generate the shortest route "with least number of turns". After some head-scratching, i came up with a solution, although with a lot of conditions added into the existing Dijkstra's algorithm implementation. Now my query is, is there a better approach for this problem(like, any existing algorithm which already does this)? My solution includes storing additional turns information in each of the nodes in the route calculation iteration, and use the same while back-tracking the route.
You shouldn't need any backtracking or substantial tweaks to Dijkstra. Simply keep track (as you do), for each node, of the least number of turns on the currently shortest route to that node. Whenever you relax an edge, if the resulting path is equally short as the currently shortest route, you pick the one with the fewest turns.
Edit: as pointed out in the comments, this approach disregards the fact that the direction of the incoming edge of the chosen route affects the number of turns for the subsequent path. That will be fixed by storing in each node the shortest distance+turns for each incoming edge or for each unique incoming angle (however you measure that).
Alternatively, in order to get by with fewer modifications of Dijkstra, you can modify the graph beforehand: Split each node into one node per incoming edge (so that each resulting node has only one of the original node's incoming edges), but copy all the outgoing edges so that each resulting node has all the outgoing edges of the original node (each of which must be directed to the appropriate copy of the node at the other end of the edge). You might see that some of the resulting nodes have multiple incoming edges, but in that case, the nodes on the other ends of those edges are all copies of the same original node and thus represent the "same" original edge - therefore, each outgoing edge can be unambiguously labeled with whether that edge represented a turn out of that node (relative to the node's incoming edges) or not. Note that the best path in the original graph will still exist in the new graph (and no better paths will have been introduced). Now, Dijkstra just needs to be modified to track the number of turns associated with the shortest path to each node. Whenever an edge from u to v is relaxed and the candidate path is as short as the shortest path you have previously found for v, compare u's turn count plus the edge's turn count (0 or 1 depending on whether the edge constituted a turn) to v's turn count, and use that as a tiebreaker.
Ultimately path finding algorithms are designed to find the lowest cost path. The definition of cost depends on the scenario. In one scenario cost might be distance but in other scenarios it might include terrain, slope, tolls etc. In your case the easiest way to model 'shortest route with least number of turns' is to derive cost from both distance and number of turns. In other words, include a cost for turning.
For example, if you are using the A* algorithm, your cost calculation between two nodes could include a cost for the distance and an additional cost if this move requires a change of direction. If a different path does not require a change of direction then it will be lower cost and the algorithm will choose that path.
The only tricky thing here will be to keep the context of the previous moves to detect the turns. In A* you are generally keeping references back to the previous node so it should be fairly straightforward to decide if the next move requires a turn.
I do not know, why no one else has stated this and why there is an accepted answer.
The problem you are trying to solve (i.e., generate the shortest route with least number of turns) is an example of the weight-constrained shortest path problem.
It is therefore NP-Complete and cannot be solved efficiently.
You can find papers that discuss solving this problem e.g. http://web.stanford.edu/~shushman/math15_report.pdf
Here's a simple heuristic. Like others have pointed out, heuristic is the game in AStar.
if (Cost > CanMaxMove) Heuristic += 1000;
// for cost per grid pt typically 10 to 30
// Cost = PtCost + CostSoFar
// higher is worse (more costly)
You simply find the best path as per usual in AStar, but discount by a large margin moves that would be out of turn. This is a very hard problem as pointed out, but easily solveable given the following condition:
Every turn a new path can and will be searched anyway: this is easily
believable, because until next turn circumstance can easily change. If
not, those are not really turns as we know them.
If that condition is ok with you, just do the above snippet. Heuristic must be discounted by the same value for all "out of this turn" moves and NOT smoothly (e.g. Heuristic += (Cost - CanMove) * 100) i.e. there must be a large difference between "this turn" and "not this turn".
So I am writing a Java program that uses the A* search algorithm. The program runs on a 2 dimensional array. It has a start location, a goal and obstacles to move around. Every object on the grid is a node.
SRRRRRRR
RXXRRXXX
RRRXXXRX
RXRRXRRR
XXXRRXRR
RRRRRRRR
XXRXRRXR
XXXXRRRG
S = Start, G = Goal, R = Valid movement tile, X = Illegal movement tile
I have two arraylists:
- openList
- closedList
openList is a list of possible movements sorted from cheapest to most expensive. closedList is a list of nodes that have been visited and will not be visited again. The algorithm will always move into the first node in the openList. This node will then be removed from openList and added to the end of closedList.
My algorithm can successfully navigate from start to goal. The problem that I am having is that I am not sure how to filter out the true path from my list of closed nodes. A* will always look for the cheapest option which means that it may not go directly to the goal. The openList ranks nodes according to the cost of movement so even if the algorithm is sitting one Node away from the goal, if there is a node that is cheaper to move into somewhere earlier on the path then it will take that cheaper node. This means that I am guaranteed to find the cheapest path, but also that at the end my closed list will be full of nodes that are not on the best path to the goal.
At the end my closedList gives me the exact path my algorithm took, not the cheapest path.
My question is: Of all the nodes that my algorithm will explore, how do I differentiate between nodes that are on the cheapest path and nodes that are not?
I would highly, HIGHLY recommend Amit Patel's A* pages, which will go into very good detail about everything you may want to know about Pathfinding.
To solve your specific problem, you need to in some way store the node you came from when you visit a node, so when you reach the goal, you just walk your way backwards along the path. This can be done with a Map<Node, Node>, or, you can make use of references to the parent node by storing something other than a Node: Something that contains the node, and a reference to the node from which you came to visit that node when you add to your lists.
It sounds like your cost function may be broken.
In A*, the cost function is always the sum of the actual cost of the path traversed so far plus a lower bound on the distance remaining. There are rules for admissability of the heuristic - the same as for a metric space IIRC.
Obvious heuristics to use for the lower-bound remaining distance in this case are...
Euclidean distance remaining - sqrt (xdist^2 + ydist^2).
Manhattan distance remaining - xdist + ydist
If the total cost estimate after taking a step along the indirect path isn't greater than after stepping directly to the goal, the only way that can be valid is if the total cost estimate is the same either way. A* won't avoid taking extra steps unless you add a tie-breaker to your cost-comparing tests. But it won't choose a higher-cost route when a direct route is available - unless your cost function is deceiving it (or your code has bugs).
In any case, that same-cost-either-way should never happen in a square grid if a possible move is directly to the goal.
There's a chance you may have implemented Dijkstra rather than A*. The cost function for Dijstra is simply the total distance travelled so far. There's no attempt to estimate distance remaining and therefore nothing to guide the search towards the goal - it explores in all directions equally.
One way to accidentally end up with Dijkstra is to use the obvious "uninformed" (but admissable) lower bound on the remaining distance - zero.
At the end it's still, of course, likely that you will have searched nodes that are off the optimum path - usually fewer than if you've got a good A* heuristic but even that can be wrong for awkward maps. See moveaway00s answer - "you need to in some way store the node you came from when you visit a node". For each node you explore, there's only one possible shortest-possible-distance to get there - if the node is on the shortest path, that backward step is a reverse step along the shortest path.
For Dijkstra, the first time you explore a location is always for the shortest way to get there. For A* that's not necessarily true IIRC (it's true for the goal node, not necessarily for other nodes explored), so you may need to store the shortest distance to the node along with the backward step.
I am going to build a graph in my java project and I am using Jung library.
My problem is that I have too many vertices and with CircleLayout or FRlayout I can't have a good visualization of the graph; I mean the vertices are very very close to each other.
Can anybody help me what I can do in such a situation?
I want to have a nice visualization of the graph in which the vertices are far enough to be able to see which vertex is connected to which vertex.
Here you see the current visualization of graph vertices.
(Originally, this was a comment, but to give the question a chance to bre removed from the "unanswered" queue: )
One important question might be what the topology of the graph is. Does the topology resemble a circle? That is, does each vertex have exactly two neighbors?
Regardless of that, you should try the other layouts as well. Particularly the SpringLayout2. It has quite some tuning parameters, but usually causes a "nice" distribution of the vertices for a wide variety of graph topologies
I implemented the Edmonds–Karp algorithm using the Pseudocode that I found in the Edmonds–Karp algorithm wiki page: http://en.wikipedia.org/wiki/Edmonds%E2%80%93Karp_algorithm
It works great, yet the algorithm output is the max flow value(min cut value), I need to the list of edges that this cut contains
I tried to change the algorithm, with no success, can you guys help?
Thank you
If you already have the flow, then compute the residual graph. Then do a depth first search from the source (or breadth first search, I don't think it matters), to compute the vertices in one half of the cut (S). The remaining vertices are in the other half of your cut, T.
This gives you your cut (S, T). If you specifically want the edges between S and T, you could iterate through all the edges, selecting the ones which connect S and T. (Though there may a be a more eleegant way to do this last part.)
Here's some pointers to help clarify how to do this for anyone in the future.
To find the S vertices, do a BFS (or DFS) search from source vertex, only following edges in which some capacity for flow is remaining. (In other words, the non-saturated edges). These ones by definition cannot be in the mincut.
To find the T vertices perform a BFS (or DFS) search from the sink vertex, only connecting to vertices that were not already added to the S set. These can have residual flow, or could be fully saturated, it doesn't matter. Because you are performing BFS from the sink, you'll need to make sure you follow the opposite direction the edge is pointed if the graph is directed. NOTE: It's important to only include vertices that can be reached from the sink in your T set, otherwise you'll end up including edges in your min-cut that do not belong there. (This is what threw me for a long time.)
Once you have these two sets of vertices you can then iterate over all the edges of the graph. Anyone that has a source node in S and a target node in T is part of your min-cut. It's important to note, though, that this is just one of many possible min-cuts. It's much more time intensive to find all the possible S-T min-cuts in a graph.
Hope this helps any future internet people trying to figure this out! Good luck!
If you already know the maximal flow, then the minimal cut is (S, T), where S is the set of vertices reachable from the source in the residual network, T is the complementary set. Edges that connect a vertex from S and a vertex from T belong to the cut.