Talk:Dijkstra's algorithm

From Rosetta Code
Revision as of 08:52, 21 December 2012 by Walterpachl (talk | contribs) (→‎Is the GO solution wrong?: new section)

Why is this a draft task?

I was surprised to see that this is a draft task. It's a pretty classic programming problem, and there are now six implementations. I don't see any obvious flaws in the problem statement. --Showell 18:33, 24 January 2012 (UTC)

It works the way it is. I would like better though if it prescribed some test data. The small example from WP would be okay. A large data set would be great, but my idea of linking words turned out kind of strange, and no other ideas have surfaced. I also think it would be nice if the task asked for solutions to note anything relevant about optimization. The priority queue in particular is a popular optimization of Dijkstra's original algorithm. —Sonia 02:42, 25 January 2012 (UTC)
I admit I didn't grok what distance metric you were using, so I ignored that part of your code. :-) In general though, I concur that a common example is a good idea. –Donal Fellows 13:50, 25 January 2012 (UTC)
The WP example just numbers the vertices, but I liked the way most solutions here use letters. The documentation requirement is something I've wanted on a number of other tasks. It should not only illustrate where variant algorithms exist, but help people comparing solutions recognize if two solutions implement the same algorithm or different variants. —Sonia 18:52, 25 January 2012 (UTC)
I'm floating a few more changes because it would be nice for this to come out of draft status looking all polished. I moved the documentation requirement to EC because I didn't want it to scare people from submitting initial solutions, and because I saw the tendency for documentation to get wordy. The directed/undirected point is important, and there's another point I'll give a new section below, single path/path tree. —Sonia 21:25, 6 February 2012 (UTC)

Java example cleanup

I've done some cleaning up of the Java example, making many of the problems in the code much less prominent. (For example, I've reduced the use of effectively-global variables and I've split the I/O from the algorithm.) More work is needed to finish transforming it from something that stank of old-skool C, but it's a long way there. I've not really addressed any of the issues raised in the alertbox (e.g., the arbitrary node limit is still there — not that you'd want to have to type in the distance matrix for anything that large anyway) but they should now be much easier for someone else to address. –Donal Fellows 03:22, 9 December 2011 (UTC)

Floyd–Warshall

The "Floyd–Warshall algorithm" is also interesting, from a graph comparison point of view, since it finds all shortest paths in a graph in O(|V|^3) time, where the most highly optimized version of Dijkstra's algorithm requires O(|E| + |V| log |V|) for a path and there are O(|V|^2) potential paths. --Rdm 20:47, 9 December 2011 (UTC)

Feel free to start a task for it. Many of these algorithms have been listed on Rosetta Code:Village Pump/Suggest a programming task but nobody has taken the initiative to start them. --Spoon! 22:47, 9 December 2011 (UTC)

Example size and heaps

I posted a couple of ideas. The WP data seems an obvious choice for the basic task. I experimented some with large graphs. My first implementation wasn't heap based and I was surprised that it could handle graphs of a few thousand vertices. I was also surprised that my heap based version only ran about 12 times faster for a graph of this size (21K nodes.)

Given how well the O(n^2) algorithm works, it should be fine for the basic task and I don't think we should fuss that it's inefficient. The heap enhancement makes a nice requirement for extra credit. To show it off seems to require a really big graph though! This thing with unixdict.txt is what I came up with for something that is repeatable. —Sonia 00:30, 10 December 2011 (UTC)

21k nodes, but how many edges? NVM, only 240k edges, which is low (a normal graph expects edge count to be somewhat comparable to V2, your graph is only about 1/2000 of that, which is to say, instead of a web, that graphis is more like trees: very few loops (is it guaranteed to be connected?) --Ledrug 00:40, 10 December 2011 (UTC)
Some possibly relavent points: 1) The Go code spent most of its time matching strings to find overlaps, that's O(n^2) with n = 20k ish; 2) the edge count is relatively low, and the code stops after reaching the target node (instead of finding the distances to all nodes). It is a valid use of the algorithm, but since the edge count isn't high and there are some peculiarities in the way distances are computed (nodes of long words tend to have longer distances to everything else, and low edge count makes the graph more tree like which sort of forces the search to follow a narrow path), the program didn't have to search too much to finish. Of 20k ish nodes, it only need to navigate through 2820. 3) minor: the tree doesn't seem to be fully connected. There may be a small number of nodes not reachable from the starting point.
The Go code is fine for what it's doing, but it's best not to draw conclusions about the performance based only on the current test case. --Ledrug 06:55, 10 December 2011 (UTC)
All very good points. Constructing the edge list took 133ms, constructing the linked representation took 225ms, and then the path search took only 7ms. It does seem likely that the graph wouldn't be fully connected. Spoon, thanks for the simplifications to the Go code! —Sonia 00:20, 11 December 2011 (UTC)

Directed vs undirected graphs

Dijkstra's algorithm can work on directed or undirected graphs. (An undirected graph can be converted into an equivalent directed graph, where for each edge in the original graph, you have two equal-weighted edges in opposite directions.) The example that the task asks the user to solve does not directly mention that it is an undirected graph; however, the solutions assume that it is an undirected graph, which is okay assuming that that was what was intended I guess. However, to be general, each solution's main algorithm implementing function should still be able to accept an adjacency matrix that is not an undirected graph. --Spoon! 08:43, 26 January 2012 (UTC)

Excellent point and something I failed to appreciate. I just looked at the picture and didn't read carefully. —Sonia 18:40, 27 January 2012 (UTC)
I just changed the task to specify a directed graph, and keeping the same example data, this changes the solution from acfe to acde, thus invalidating existing solutions. Sure the task could be written to keep acfe the correct solution, but I thought directedness was important enough to point out with a new solution. —Sonia 21:25, 6 February 2012 (UTC)

Single path / Path Tree

WP mentions the algorithm can produce a path tree, but discussions and examples tend to talk about single paths. I think it's fine for the task to ask for a single path solution, but now while it's in draft is the time for people to speak up for path trees if they like. Interestingly, Dijkstra's '59 paper doesn't mention path trees, but only the single path problem. (Problem 1 in the paper is a minimal spaning tree, which is something different.) —Sonia 21:25, 6 February 2012 (UTC)

Is the GO solution wrong?

[a c d e] length 26 ... or what do I misunderstand?