Content deleted Content added
m Reverted edit by 137.132.215.131 (talk) to last version by JustinBlank |
|||
| (48 intermediate revisions by 29 users not shown) | |||
Line 1:
{{WikiProject banner shell|class=C|vital=yes|1=
{{WikiProject Mathematics|priority=Mid}}
{{WikiProject Computer science|importance=high}}
}}
== Usage in 3d printing ==
The algorithim is used within the 3d printing slicer cura to generate tree supports, could a note about this application (along potentially with others be added)? (source of use in cura https://github.com/Ultimaker/CuraEngine/pull/655/commits/5004290e594332d23dcb94cc776144b5804b72e8 ) <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Gsykesvoyage|Gsykesvoyage]] ([[User talk:Gsykesvoyage#top|talk]] • [[Special:Contributions/Gsykesvoyage|contribs]]) 14:33, 22 October 2020 (UTC)</small> <!--Autosigned by SineBot-->
== Developed by Vojtech Jarnik? ==
Why is it stated that the algorithm was originally developed by Vojtech Jarnick? The cited paper actually contains description of Boruvka's algorithm (initially all vertices are fragments, and on each step a minimum edge for each fragment is added to MST, until there remains only one fragment). [[User:Reminiscenza|Reminiscenza]] ([[User talk:Reminiscenza|talk]]) 19:14, 30 May 2015 (UTC)
:In the cited paper, the relevent part is on page 60. Note that in step 1, he chooses any one vertex and in step k, he chooses one vertex from the vertices 1-k and one vertex from (k+1)-n. The Germant translation explains that same algorithm. The PDF I checked for is this one: http://dml.cz/bitstream/handle/10338.dmlcz/500726/Jarnik_01-0000-31_1.pdf [[User:Oracions|Petr Hudeček]] ([[User talk:Oracions|talk]]) 15:10, 11 June 2015 (UTC)
== complexity by binary heap ==
Is "(V+E)log(E)" really correct?
Thinking a heap H of edges which are directly connecting to the growing spanning tree.
All edges can be added to and removed from the heap H.
(Every edge can be adjacent to the growing spanning tree. This way edges can be added to the heap.
One edge can be added to the spanning tree, or become loop-making one and get disqualified.This way they can be removed so that
edges heap becomes {}.) I suspect that (V+E)log(E)-> E log(E) argument is missing something. I suspect (E+E) log(E) -> E log(E) is an
exhaustive argument.
--[[User:Timothy Redt|Timothy Redt]] ([[User talk:Timothy Redt|talk]]) 01:08, 22 July 2012 (UTC)
== C++ code for Prim's using adjacency matrix A ==
A[i][j] is
#include <algorithm>
Line 31 ⟶ 54:
}
}
== Colored lines in graph ==
Line 56 ⟶ 78:
:Which type would work best? [[User:Shen|Shen]] 16:44, 17 February 2006 (UTC)
::I made some new images using thinner and thicker lines, it should be clearer now. [[User:Shen|Shen]] 22:06, 19 February 2006 (UTC)
::I'd urge the use of colours vs. different sorts of lines here, since "graph colouring" is a very common term in the literature of computer science, and is a ''de facto'' standard way of denoting groups of edges or nodes, in discussion even more than pictorially. Explaining that the colouring is represented by dashes and whatnot would be convoluted. However using colours accessible to the colourblind is always a good idea. Also Shen, I don't think the current choice of colours is a good one (though I am not colour blind and therefore cannot tell if they are differentiable). See [http://webdesign.about.com/od/accessibility/a/aa062804.htm this article]. [[User:DaveWF|DaveWF]] 07:37, 14 February 2007 (UTC)
== Suggestion of a better explanation ==
Line 77 ⟶ 100:
I also think that you NEED to mention that a edge should only be used if it results in a cycle, which is obvious to some, but really should be spelt out.
:Don't you mean if it *doesn't* result in a cycle? - [[User:Solberg|Solberg]] 06:57, 7 July 2006 (UTC)Solberg
::He must've. You only add an edge if it's of minimum cost and doesn't cause a cycle. [[User:DaveWF|DaveWF]] 07:42, 14 February 2007 (UTC)
== Something isn't right ==
Line 110 ⟶ 134:
--[[User:Opium|Opium]] 12:01, 5 September 2006 (UTC)
Updated again [[User:Opium|Opium]] 08:40, 6 September 2006 (UTC)
:You are correct, how come this still isn't fixed? The algorithm in this page is simply WRONG! [[User:Yomach|Yomach]] ([[User talk:Yomach|talk]]) 21:58, 25 June 2010 (UTC)
<blockquote></blockquote>
* I don't think that's right. From my understanding, Prim's works like this:
Line 117 ⟶ 144:
- Add that node and the corresponding least edge to T
- T is then the minimum spanning tree
==Corrections==
Line 130 ⟶ 156:
:** Remove ''q'' from ''Q''
:** Add ''q'' to ''A'', under vertex ''a''
:This is how I interpreted the section '''Prim's algorithm''' in ''Introduction to Algorithms'' (chapter 23, section 2, {{ISBN
== pseudocode cleanup ==
Line 140 ⟶ 166:
== edit to time complexity? ==
I don't know about the fibonnaci heap (and I honestly haven't implemented the adjacency matrix, but
{| class="wikitable"
Line 153 ⟶ 179:
All of the algorithms have do |V|-1 iterations. The adjacency matrix implementation takes O(''V'') time to find the minimum, whereas the other implementations '''including the fibonnaci heap?''' take O(log(''V'')) time. As described above, all of vertices adjacent to the last vertex added are updated. There are, on average, E/V adjacent vertices. The adjacency matrix '''and fibonnaci heap ?''' take constant time to update the minimum distance, whereas the binary heap takes log(V) time. The [[Fibonacci heap]] is significantly faster when the graph is dense enough that ''E'' is <math>\Omega</math>(''V''log ''V''). --gatoatigrado <!-- ~~~ -->
:It's sort of correct, sort of not. First, it would be clearer if you listed the time to update a single edge, because it's possible that some vertices have many more than E/V edges to update and that others have many fewer. Yes, it averages out, but if you think the table needs to be expanded to describe the time per operation then you might as well describe the time per operation and not the time per aggregated average of some sequences of operations. Second, the Fibonacci heap does take O(log V) to remove the minimum vertex (that, rather than finding the minimum, is the slow part for both it and the binary heap) and constant time to do an edge update. But both of those time bounds are [[Amortized analysis|amortized]], meaning again that it's true only when averaged over a sequence of operations. Individual remove-min or edge updates can take much longer.
:If you're going to update this, I think it would make sense to include also a k-ary heap. There seems to be no WP article on it but it's just like a binary heap with a higher branching factor. By using a branching factor of k, one can make the edge update time be O(log(V)/log(k)) at the expense of making the remove-min time go up to O(k log(V)/log(k)) — choosing k=E/V gives an algorithm with total time O(E log(V)/log(E/V)). It's not as good as Fibonacci theoretically but much simpler in practice. —[[User:David Eppstein|David Eppstein]] 03:18, 20 February 2007 (UTC)
:A one-shot search of the adjacency matrix for the minimum edge leaving the tree/cloud is Theta(E), not O(V). Note that you cannot simply check the edges for one of the vertices in the tree. Hence, without any smart bookkepping, which doesn't seem implied, e.g. Cormen's has a complexity of O(VE), not O(V^2). What is the proposed algorithm for the adjacency matrix search with O(V^2) worst-case complexity? [[User:C. lorenz|C. lorenz]] ([[User talk:C. lorenz|talk]]) 16:44, 25 September 2008 (UTC)
::Maintain throughout the algorithm a vector of distances from the tree to the remaining nodes. Whenever each new node is added to the tree, use its row of the distance matrix to update the tree's distance vector. Scanning the tree's distance vector to find each new nodes takes O(V) and updating the distance vector also takes O(V). —[[User:David Eppstein|David Eppstein]] ([[User talk:David Eppstein|talk]]) 00:51, 27 September 2008 (UTC)
:::I'd say that calls for some bookkeeping, but it's simple enough and I should have thought of it. Thanks, and sorry. —[[User:C. lorenz|c. lorenz]] ([[User talk:C. lorenz|talk]]) 14:48, 7 October 2008 (UTC)
::::Just a note to clarify the above explanation (wasn't obvious to me). You keep an array of distances from each remaining node to closest node in tree. When one node is added to the tree, you only need to check if the distances of remaining nodes to new node is smaller than previous closest. This makes it < |V| checks for every node added -> O(V). <small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/212.250.200.210|212.250.200.210]] ([[User talk:212.250.200.210|talk]]) 09:19, 27 October 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
== Isn't there anything wrong in the example ? ==
Please be certain about this sentence : "vertex '''D''' has been arbitrarily chosen as a starting point." , i think the starting point is '''A''' not '''D''', if i am right , then you have to change the description of the second step in addition to the first step : i suggest the following :
This is our original weighted graph. This is not a tree because the definition of a tree requires that there are no circuits and this diagram contains circuits. A more correct name for this diagram would be a graph or a network. The numbers near the arcs indicate their weight. None of the arcs are highlighted, and vertex '''A''' has been arbitrarily chosen as a starting point.
The second chosen vertex is the vertex nearest to '''A''': '''D''' is 5 away, '''B''' is 7. Of these, 5 is the smallest, so we highlight the vertex '''D''' and the arc DA.
--[[User:Tameralkuly|Tameralkuly]] 18:10, 26 January 2007 (UTC)
:No, there is nothing wrong with this example. Just because '''A''' is the first letter in the alphabet does not mean you have to start with '''A'''. In fact, I think starting from '''D''' is more instructive because it demonstrates the arbitrariness. As an expert in Prim's algorithm, I feel confident this is the case and have removed the cleanup tag. [[User:Epachamo|Epachamo]] 16:30, 23 April 2007 (UTC)
== Weights not negative? ==
Why can't the graph contain negative weights in the example? Isn't this a little confusing for people who just learned Dijkstra? <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/78.21.33.78|78.21.33.78]] ([[User talk:78.21.33.78|talk]]) 05:48, 29 May 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
== Simpler end of proof ==
Proof can be made slightly simpler at the end. We are in case Y != Y_1, and Y_1 is minimal spanning tree. There two possibilities, Y is also minimal spanning tree (other one with the same sum of the weight), which is OK, or Y have different sum of weight. If it have different number, then if must of course have more than sum for Y_1. At the ending wee see that Y_2, constructed from Y by removing f and adding e, have sum of weights smaller (or equal) than Y itself, and is again spanning tree. If it is equal then it s OK for us. If it is greater, this leads to contradiction (Y_2 cannot have smaller sum of weight from Y_1, which already have smallest possible one). Therfore Y != Y_1, and sum of Y < sum of Y_1, is impossible. End of proof. --[[Special:Contributions/91.213.255.7|91.213.255.7]] ([[User talk:91.213.255.7|talk]]) 04:28, 7 January 2011 (UTC)
== All black image: Maze Generation ==
The "Maze Generation" image used in this article renders all black and doesn't change. I've viewed this article with Chrome, Firefox and IE under Windows XP and they're all the same. When I go [http://upload.wikimedia.org/wikipedia/commons/d/da/Mazegeneration.gif directly to the GIF], I can see that it's actually an animated GIF demonstrating the generation of a maze. Seeing how this image is only indirectly related to the topic (even if it were working properly), I think this image should be removed. <span style="white-space:nowrap;"><b>[[User:Justin W Smith|Justin W Smith]]</b> <i><sup>[[User talk:Justin W Smith|talk]]</sup>/<sub>[[Special:Contributions/Justin W Smith|stalk]]</sub></i></span> 22:00, 17 January 2011 (UTC)
: to me it also seems that this maze is not generated with Prim's algorithm, as there are multiple "maze compononets" that grow into each other. Prim's algorithm only has one tree that grows to become a spanning tree. --[[Special:Contributions/134.96.156.103|134.96.156.103]] ([[User talk:134.96.156.103|talk]]) <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|undated]] comment added 10:13, 21 January 2011 (UTC).</span><!--Template:Undated--> <!--Autosigned by SineBot-->
== Djikstra and Prim algorithms ==
It is not clear the meaning of the sentence saying that Dijkstra "rediscovered" the algorithm: it seems to suggest that Prim's algorithm and the famous Djikstra's shortest path algorithm are the same, while they solve two different problems (minimum spanning tree and single-source shortest path problem). The quote should be made more precise or eliminated <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/93.36.87.111|93.36.87.111]] ([[User talk:93.36.87.111|talk]]) 12:01, 24 January 2014 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
:No, it means precisely what it says: Dijkstra rediscovered the same minimum spanning tree algorithm. —[[User:David Eppstein|David Eppstein]] ([[User talk:David Eppstein|talk]]) 17:09, 24 January 2014 (UTC)
== [[:File:MAZE 30x20 Prim.ogv]] to appear as POTD ==
Hello! This is a note to let the editors of this article know that [[:File:MAZE 30x20 Prim.ogv]] will be appearing as [[Wikipedia:picture of the day|picture of the day]] on June 12, 2015. You can view and edit the POTD blurb at [[Template:POTD/2015-06-12]]. If this article needs any attention or maintenance, it would be preferable if that could be done before its appearance on the [[Main Page]]. Thanks! — [[User:Crisco 1492|Chris Woodrich]] ([[User talk:Crisco 1492|talk]]) 23:50, 22 May 2015 (UTC)
{{POTD/2015-06-12}}
== Linear Time For Dense Graphs ==
The article currently claims "However, for graphs that are sufficiently dense, Prim's algorithm can be made to run in linear time, meeting or improving the time bounds for other algorithms.[10]". The reference is to Tarjan, "Data Structures and Network Algorithms", page 77. While I am only now learning about Prim's algorithm, I do not believe this is accurate. The page states:
: The running time of this implementation is dominated by the heap operations, of which there are n — 1 deletemin operations, n — 1 insert operations, and at most m — n + 1 siftup operations. By the analysis of §3.2, the total running time is 0(n d logd n + m logd n).
I cannot find anything on that page that indicates that the algorithm is ever linear. [[User:JustinBlank|JustinBlank]] ([[User talk:JustinBlank|talk]]) 19:06, 27 October 2024 (UTC)
| |||