Talk:Disjoint-set data structure

message: This is also known as MF-Set (Merge-Find-Set), isn't it?--216.244.232.1 03:37, 18 Oct 2004 (UTC)
replies: text: I was not aware of this. Thanks. I've added this information and the appropriate redirects (merge-find set, merge-find-set, merge-find data structure). Derrick Coetzee 05:45, 18 Oct 2004 (UTC)
thread_title: disjoint set

message: The first description of the disjoint-sets forest idea is found in:
Bernard A. Galler and Michael J. Fisher. "An improved equivalence algorithm",
Communications of the ACM, Volume 7, Issue 5 (May 1964), pages 301-303.
Further reference:
Zvi Galil and Giuseppe F. Italiano.  "Data structures and algorithms for disjoint set union problems",
ACM Computing Surveys, Volume 23, Issue 3 (September 1991), pages 319-344.
:Thanks for the references. I'll add them. Deco 04:10, 24 December 2005 (UTC)
thread_title:  Some references 

message: While the source code is no doubt useful, it's not really commented on that much in the rest of the entry. Might it belong in Wikisource? --Jacj 14:21, 8 May 2006 (UTC)
thread_title:  Does the source code belong here? 

message: This paper of Hantao Zhang , a CS professor at the University of Iowa, claims that the bound given in the Wikipedia article is not the best possible, and that a more careful analysis shows the algorithm to have linear worst-case time.  I am following up with Zhang about the provenance of the paper, and whether it was published.  -- Dominus (talk) 23:58, 21 January 2008 (UTC)
replies: text: I was going to say that there's a proven lower bound, but the paper addresses this. However, I'm not confident that this paper, which is still very new, has been thoroughly peer-reviewed. I'd like to see it published in a conference or journal or at least a workshop first. Dcoetzee 03:28, 22 January 2008 (UTC)
replies: text: It has not yet been published or peer-reviewed.  It is under submission to STOC 2008. Zhang had not been aware of the  Fredman and Saks thing, although he had been aware of similar work that proves the same result.  I will post an update if I learn anything new.  -- Dominus (talk) 23:51, 28 January 2008 (UTC)
replies: text: The paper was rejected from STOC 2008. -- Dominus (talk) 15:15, 27 February 2008 (UTC)
replies: text: Is there any indication of why the paper was rejected -- did the reviewers find mistakes, or did they simply not think it was important enough? 24.80.10.198 (talk) 03:28, 14 April 2008 (UTC)
replies: text: I suppose there were mistakes in it, since Zhang has removed it from his website. Does someone remember the title of the paper? Adrianwn (talk) 09:36, 18 April 2008 (UTC)
replies: text: The title was The Union-Find Problem Is Linear.  I still have a copy.  -- Dominus (talk) 13:56, 18 August 2008 (UTC)
replies: text: Isn't the non-linear lower bound only valid under a separation assumption (i.e. disjoint sets representations do not share memory)? The following paper solves some offline version of the union-find problem in linear time by using a lookup table for small sets: "A linear-time algorithm for a special case of disjoint set union" (1983) by Gabow and Tarjan. Aureooms (talk) 16:24, 18 September 2022 (UTC)

text: What about the paper mentioned in e-maxx.ru: Wu, Otoo "A Simpler Proof of the Average Case Complexity of Union-Find with Path Compression"? https://www.researchgate.net/profile/Kesheng-Wu/publication/235708752_A_simpler_proof_of_the_average_case_complexity_of_union-find_with_path_compression/links/540bd2160cf2df04e7509fe0/A-simpler-proof-of-the-average-case-complexity-of-union-find-with-path-compression.pdf?origin=publication_detail It is for average case, but the complexity analysis seems pretty short if the paper is valid.  Wqwt (talk) 15:10, 25 December 2022 (UTC)
thread_title:  Hantao Zhang says that the time is linear 

message: I will shorten the Applications section; in particular I will remove all subsections except the one related to undirected Graphs. Rationale: Wikipedia is not a textbook, it is also not a programming manual or guide. Books or websites about algorithms or programming are better suited for such descriptions; however, references to them would be appropriate. Adrianwn (talk) 09:50, 18 April 2008 (UTC)
replies: text: I disagree with this edit and with your interpretation of "Wikipedia is not a textbook". The policy page goes on to say: "It is not appropriate to create or edit articles which read as textbooks, with leading questions and step-by-step problem solutions as examples." This seems to imply that this has more to do with style than content; applications of a data structure are certainly relevant to the data structure, just as carbon dioxide describes industrial uses of that chemical in great detail. Dcoetzee 20:57, 18 April 2008 (UTC)
replies: text: You are right, the applications of this data structure should be listed. However, the Applications section contained a lot of those step-by-step instructions. Could you please rewrite that section in a shorter, more concise way? I would do it myself if I understood more about these specific subjects. Adrianwn (talk) 07:20, 19 April 2008 (UTC)
replies: text: You're right, it ought to summarize the applications rather than detail the application algorithms, but the point is to describe the mapping of various application domain events onto disjoint-set operations. I'll take a look at it again, at least the ones that I wrote. Dcoetzee 06:06, 30 April 2008 (UTC)

text: Also, "weighted union heuristic" is a term taken directly from CLRS, and it's used in many publications; you would have found many more Google hits if you tried searching  for it with the hyphen ("weighted-union heuristic"). For this reason I've added it back. Dcoetzee 21:02, 18 April 2008 (UTC)
replies: text: Nope, still gives about 200 hits (Google doesn't care much about hyphens), and only 11 hits in Google Scholar. Also, as far as I remember, CLRS never calls it "the" weighted-union heuristic, but rather "a" weighted-union heuristic (i.e., a description of the method instead of a name for it). What do you think about: "When the length of each list is tracked, the time needed can be ameliorated by always appending the smaller list to the longer. Using this "weighted-union heuristic", a sequence of [...]" ? Adrianwn (talk) 06:59, 19 April 2008 (UTC)
replies: text: Sure, sounds fine. Dcoetzee 06:08, 30 April 2008 (UTC)

text: If step by step instructions have been removed from the article, maybe they could be transferred to wikibooks and linked to from here.  —Preceding unsigned comment added by 207.241.238.233 (talk) 00:08, 30 April 2008 (UTC)
thread_title:  Shorten Applications section 

message: Why is this citation in the reference section?  The article doesn't appear to actually refer to it.
:J. A. Spirko and A. P. Hickman, Molecular-dynamics simulations of collisions of Ne with La@C82, Phys. Rev. A 57, 3674–3682 (1998).  —Preceding unsigned comment added by 207.241.238.233 (talk) 00:06, 30 April 2008 (UTC)
thread_title:  molecular dynamics 

message: in the first section, it says # Find: Determine which set a particular element is in. Also useful for determining if two elements are in the same set.
But if this a disjoint set, how can an element be in two sets?  —Preceding unsigned comment added by 24.1.30.246 (talk) 16:18, 7 April 2009 (UTC)
replies: text: You misread it - it says "determine if two elements are in the same set", not "determine if two sets both contain the same element". Dcoetzee 22:57, 7 April 2009 (UTC)
thread_title:  first bullet 

message: The quote from the paper is unclear: is the Ackerman complexity the least an algorithm must use (a lower bound), or is it an upper-bound (the truly optimal complexity is no more than the Ackerman complexity)? --Gwern  (contribs) 01:36 11 January 2010 (GMT)
:I think it means that the Ackermann function is an upper bound for all inputs, and a lower bound for some inputs (i.e., the worst case). — Adrianwn (talk) 07:26, 11 January 2010 (UTC)
thread_title:  Complexity 

message: Is it Union(x,y) and x,y are representatives ? Cormen writes they are not.
I am confused. The difference is whether we have to find the roots or not. Webskipper (talk) 15:58, 21 May 2010 (UTC)
replies: text: It depends on how Union(x,y) is defined; the pseudocode in this article does not assume that x and y are representatives. – Adrianwn (talk) 16:22, 21 May 2010 (UTC)
thread_title:  How is Union defined ? 

message: The implementation listed as
Implementation of Disjoint-set Forests in C++, by Bo Tian
seems not to update the path (it dont do path compression)
which is the hole point.  — Preceding unsigned comment added by 85.164.124.173 (talk) 17:57, 20 July 2011 (UTC)
replies: text: I've removed the C++ links, as the code was poor quality. Follow the pseudocode in the article instead. The Python implementation also looks reasonably okay. If you're looking to do this in C++ in a production setting you should be using the Boost implementation instead. Dcoetzee 04:46, 21 July 2011 (UTC)
thread_title:  Error in the implementation 

message: The article claims that concatenation of linked lists in constant time.  This is not so, you have to append the second list to the tail of the first one, which requires O(|L1|) where L1 is the first list.
To get such a limit, we need more, such as a pointer to the end of our lists.  These are not strictly "linked-lists" and I suggest that this is mentioned.
STL (for C++) provides "splice" on lists which is O(1).  To support this, lists are actually doubly linked lists, and for instance in GNU C++ (libstdc++), they are even circular doubly-linked list with a direct access to the last element.
Akim Demaille (talk) 13:33, 23 October 2011 (UTC)
replies: text: Keeping a tail pointer for a linked list is a trivial extension and extremely common in practice (I'd argue, more common than not keeping such a tail pointer). I really don't think this requires any further explanation. It is true that STL splice is useful for implementing list merging in C++, but that's an implementation detail and not terribly relevant here. Dcoetzee 20:10, 24 October 2011 (UTC)

text: You're confusing the linked list "find" operation with the disjoint-set data structure "find" operation. The role of the first is to find a list element with a particular value. The role of the second is, given an element, to find its set representative - which we have chosen to be the head of the list that element belongs to. I've edited to attempt to clarify this. Let me know if this can be improved further. Dcoetzee 01:41, 26 October 2011 (UTC)
thread_title:  Linked lists 

message: Maybe I'm missing something very simple, but why it said that the run time of MakeSet in the Disjoint-set forests implementation is O(log(n))?
Shouldn't it supposed to be O(1)?
Thanks  — Preceding unsigned comment added by 79.177.179.58 (talk) 11:00, 14 January 2016 (UTC)
replies: text: Fixed. Glrx (talk) 02:54, 16 January 2016 (UTC)
thread_title:  Run time of MakeSet in Disjoint-set forests 

message: Operations Section 
Find Sub-Section 
if condition x.parent != NULL is incorrect it should be x.parent != x, because at the return of function null will be return instead of root i.e when find() will be used in union(), find(x) will return NULL instead of Root  — Preceding unsigned comment added by CY5 (talk • contribs) 15:48, 18 February 2017 (UTC)
thread_title:  if Condition is incorrect in  Find function 

message: Content merged from Talk:Proof of O(log*n) time complexity of union–find.--Salix alba (talk): 07:05, 23 April 2020 (UTC)
replies: text: Rank as used in this data structure is defined by the algorithm. It is indeed an upper bound on height, where height of a node is the number of edges from the node to its deepest leaf. This notion of height is standard. The notion of rank is not standard but specific to the algorithm. There is another way to define the rank of a node - it is the height that this node would have if no compressions took place. AmirOnWiki (talk) 12:31, 11 September 2023 (UTC)
thread_title:  Proof 

message: The formatting of this page (especially of the mathematics) was pretty cruddy, so I went through and did what I could, fixing up some grammar while I was at it. I haven't actually read the article yet, so it's quite possible I goofed something up by misinterpreting it.Dfeuer (talk) 05:27, 6 July 2012 (UTC)
thread_title:  Formatting makeover 

message: Lemma three isn't explicitly mentioned anywhere after its statement. Dfeuer (talk) 06:14, 6 July 2012 (UTC)
thread_title:  Lemma 3 

message: The proof of Lemma 2 only considers "Makeset" and "Union", but not "Find";
and indeed path compression will cause a violation of the claim.
This raises (again) the following question:  — Preceding unsigned comment added by Martin Ziegler (talk • contribs) 09:33, 4 April 2018 (UTC)
thread_title:  Lemma 2 wrong? 

message: Whose proof is this? If it was previously published, is there a copyright problem? If not, is it prohibited as original research? Dfeuer (talk) 09:14, 7 July 2012 (UTC)
thread_title:  Original research? 

message: The proof is basically that of Hopcroft and Ullman (1973).
However, this short version does not clearly make use of the hypothesis that each Find leads to a path compression, which is crucial for the result to be correct.
An extra explanation showing where and how that hypothesis is used seems needed.  — Preceding unsigned comment added by Bsalvy (talk • contribs) 21:26, 15 November 2018 (UTC)
thread_title:  Missing steps in that proof? 

message: As I read the current proof, it reads as if the forest is unchanging.  The original proof by Hopcroft and UllmanSIAM J. Comput. Vol. 2, No. 4, December 1973, Set Merging Algorithms, J. E. Hopcroft and J. D. Ullman is careful (when defining the ranks, and when proving the analogous lemmas), to carefully account for how the trees change as a result of find and union operations.  This issue seems to be swept under the rug in the current proof here, making it very hard to understand the details. Nealeyoung (talk) 23:18, 22 March 2019 (UTC)
thread_title:  Gaps in the proof 

message: I am confused with the definition of rank as the way it is used in this article differs from my understanding.
My understanding is as follow:
* Rank: Property of a Tree - The number of nodes from the leaf to root including the root itself; thus, a singleton would have a rank of one.
* Height: Property of a Tree - The number of edge from the leaf to the root; thus a singleton would have a height of zero.
The article's definitions:
* Rank: Rank is the upper bound of height, and a singleton's rank and height are both 0.
Antmaker (talk) 15:31, 21 April 2022 (UTC)
replies: text: Rank as used in this data structure is defined by the algorithm. It is indeed an upper bound on height, where height of a node is the number of edges from the node to its deepest leaf. This notion of height is standard. The notion of rank is not standard but specific to the algorithm. There is another way to define the rank of a node - it is the height that this node would have if no compressions took place. AmirOnWiki (talk) 12:31, 11 September 2023 (UTC)
thread_title:  Rank and Height definition