Can someone help me with this question
I am still confused weather Dijkstra's algorithm works with negative edges or not
this question is from Grokking Algorithms book and in its errata it is said that this question has a possible answer
how does it has a possible answer with a negative edge?
First of all Dijkstra's algorithm won't work on all negative weighted graphs, but on this particular case you can see that the negative weight not make any different on the shortest way to get from the starting point to any other point on the graph. this is why you will get the same result with the negative edge or without.
The idea why Dijkstra's won't work on negative weighted graphs is explained pretty well here (thanks to Amit) -> Why doesn't Dijkstra's algorithm work for negative weight edges?
It's been literally 10 years since I last touched anything to do with Dijkstra, but I think this one doesn't break because every time you pass over the negative portion, the loop still increases the sum (minus 1 vs several plus 2). This way, the path with the negative is discarded. But change that minus 1 to minus 5 and then you have a problem.
I'm not on my PC right now to apply this graph to my 10 year old homework, but I'm pretty sure that's what's going on.
Related
It's stated in a book that "Dijkstra's algorithm only works with Directed Acyclic Graphs".
It appears the algorithm works for graphs with cycles too as long as there are no negative cycles. Is that correct?
Edit 1:
The book "Grokking Algorithms" -Aditya Bhargava.
Chapter 7. Page 122.
I'm the author of Grokking Algorithms. Sorry for this error—Dijkstra's algorithm does work on graphs with cycles, as long as it is a positive weight cycle. I have updated the errata page to reflect this error. Dijkstra's doesn't work on negative weight cycles, and here's an image that explains why:
Actually, it works as long as all edge weights are non-negative. This is a stronger condition as "no negative cycles". On the other hand it would not work on a DAG with negative weights. So, provided you cited correctly, the statement from the book is wrong for two reasons.
Btw. if you have negative cycles, there may no longer be a shortest path since you may cycle an infinite number of times and go down with your cost as much as you like.
In case someone is looking for an example DAG with negative weights where Dijkstra does not give the correct shortest path: http://stackoverflow.com/a/6799344/3924118
I am using A* in order to solve the Asymmetric Traveling Salesman problem.
My state representation has 4 variables:
1 - Visited cities (List)
2 - Unvisitied cities (List)
3 - Current City (Integer)
4 - Current Cost (Integer)
However, even tho I find many path-construction algorithms such as Nearest Neighbor, k-opt and so on, I can't find an heuristic suitable for A*, which is, a h(n) function that takes a state as input and returns an integer corresponding to that state's quality.
So my question is, are there such heuristics? Any recommendations?
Thanks in advance
The weight of the minimum spanning tree of the subgraph that contains all unvisited vertices and the current vertex is a lower bound for the cost to finish the current path. It can be used with the A* algorithm as it can't overestimate the remaining distance (otherwise, the weight of the remaining path is smaller than the weight of minimum spanning tree and it spans the given vertices, which is a contradiction).
I've never tried it though so I don't know how well it'll work in practice.
There always are: h(n) = 0 always works. It is useless, turning A* into Dijkstra, but it's definitely admissible.
An other obvious one: let h(n) be the shortest edge from the current city back to the beginning. Still a huge underestimation, but at least it's not necessarily zero. It's obviously valid, the loop has to be closed eventually and (given this partial route) there is no shorter way to do it.
You can be a bit more clever here, for example you could use linear programming (make two variables for each edge, one for each direction, then for every city make a constraint forcing the sum of entering edges to be 1 and a constraint forcing the sum of exiting edges to be one, weights are obviously the distances) to find an underestimation of the length from the current node back to the beginning while touching every city in the set of unvisited cities. Of course if you're doing that, you might as well drop A* and just use the usual integer linear programming tricks. A* doesn't seem like a good fit here (especially in the beginning, the branching factor is too high and the heuristics won't guide it enough yet), but I haven't tried this so who knows.
Also, given the solution from the LP, you can improve it a lot by using some simple tricks (and some advanced tricks that whole books have been written about, but let's not go there, read the books if you want to know). For example, one thing the LP likes to do is form lots of little triangles. This will satisfy the degree constraints everywhere locally and keeps everything nice and short. But it's not a tour, and forcing it be more like a tour will make the heuristic higher=better. To remove the sub-tours, you can detect them in the fractional solution and then force the number of entries to the subgraph to be at least 1 (it may have to become more than 1 at some point, so don't force it to be exactly 1) and force the number of exits to be at least 1, by adding the corresponding constraints and solving again. There are many more tricks, but this should already give a very reasonable heuristic, much closer to the actual cost than using any of the overestimating heuristics and dividing them by their worst case overestimation factor. The problem with those is that usually the heuristic is pretty good, much better than their worst case factor, and then dividing by the worst case factor really kills the quality of the heuristic.
I know that Dijkstra's algorithm can be used only on positive lengths of edges, and Bellman-Ford can be used when the graph also has negative ones.
Suppose we have a graph with only positive edges, though. Will Bellman-Ford give the same results as Dijkstra?
Yes, it will give the same results. It will run slower, though, as it could also have been used for graphs with negative edges (subject to the absence of negative cycles). If you look at the proof of BF's correctness, there is no assumption there that some of the edges are negative.
I want to add something to Ami Tavory's answer. Bellman-ford's algorithm can be made a little bit faster if you can detect that on any pass, there is no node value update, then return from there. If there is no node update then it proves that every node traversal is complete.
I am stuck on a two part practice problem regarding the subjects mentioned in the title.
The first part of the question asks:
By considering the complete graph with n verticies, show that the maximum number of simple paths between two verticies is O((n-1)!). (I am assuming I am supposed to show this somehow with a formal definition)
The second portion of the questions asks:
Give an example where Dijkstra's algorithm gives the wrong answer in the presence of a negative edge but no negative cost cycles.
Thanks for any help!
I am working with A-star algorithm, whereing I have a 2D grid and some obstacles. Now, I have only vertical and horizontal obstacles only, but they could vary densely.
Now, the A-star works well (i.e. shortest path found for most cases), but if I try to reach from the top left corner to the bottom right, then I see sometimes, the path is not shortest, i.e. there is some clumsiness in the path.
The path seem to deviate from the what the shortest should path should be.
Now here is what I am doing with my algorithm. I start from the source, and moving outward while calculating the value of the neighbours, for the distance from source + distance from destination, I keep choosing the minimum cell, and keep repeating until the cell I encounter is the destination, at which point I stop.
My question is, why is A-star not guaranteed to give me the shortest path. Or is it? and I am doing something wrong?
Thanks.
A-star is guaranteed to provide the shortest path according to your metric function (not necessarily 'as the bird flies'), provided that your heuristic is "admissible", meaning that it never over-estimates the remaining distance.
Check this link: http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html
In order to assist in determining your implementation error, we will need details on both your metric, and your heuristic.
Update:
OP's metric function is 10 for an orthogonal move, and 14 for a diagonal move.
OP's heuristic only considers orthogonal moves, and so is "inadmissible"; it overestimates by ignoring the cheaper diagonal moves.
The only cost to an overly conservative heuristic is that additional nodes are visited before finding the minimum path; the cost of an overly aggressive heuristic is a non-optimal path possibl e being returned. OP should use a heuristic of:
7 * (deltaX + deltaY)
which is a very slight underestimate on the possibility of a direct diagonal path, and so should also be performant.
Update #2:
To really squeeze out performance, this is close to an optimum while still being very fast:
7 * min(deltaX,deltaY) + 10 * ( max(deltaX,deltaY) -
min(deltaX,deltaY) )
Update #3:
The 7 above is derived from 14/2, where 14 is the diagonal cost in the metric.
Only your heuristic changes; the metric is "a business rule" and drives all the rest. If you are interested on A-star for a hexagonal grid, check out my project here: http://hexgridutilities.codeplex.com/
Update #4 (on performance):
My impression of A-star is that it staggers between regions of O(N^2) performance and areas of almost O(N) performance. But this is so dependent on the grid or graph, the obstacle placement, and the start and end points, that it is hard to generalize. For grids and graphs of known particular shapes or flavours there are a variety of more efficient algorithms, but they often get more complicated as well; TANSTAAFL.
I'm sure you are doing something wrong(Maybe some implementation flaw,your idea with A* sounds correct). A* guarantee gives the shortest path, it can be proved in math.
See this wiki pages will gives you all the information to solve your problem .
NO
A* is one of the fastest pathfinder algorithms but, it doesn't necessarily give the shortest path. If you are looking for correctness over time then it's best to use dijkstra's algorithm.