Talk:Binary search tree/Archive 2

No Duplicates?
It seems that there is disagreement in the definition of a binary search tree. The article currently says that there must be no duplicates (and there are sources online that back it up), but many standard implementations of BSTs support duplicates, and Nick Parlante, at Stanford, says that they can contain duplicates (http://cslibrary.stanford.edu/110/BinaryTrees.html). Does anyone have an authoritative source (eg, CLRS or something by Knuth) on the subject? Meviin (talk) 21:15, 27 November 2013 (UTC)
 * There's also this - in direct contradiction - "The BST property--every node on the right subtree has to be larger than the current node and every node on the left subtree has to be smaller than (or equal to) the current node"
 * It's not even mentioned in many trees-related articles I've seen here. Either duplicates are permitted or they're not, but it's often not stated. If there's some disagreement about this, at least note it, rather than hoping no on will notice the omission.  Also, if you are going to assume yes or no, make sure that all the rest of the article complies.

--Akwillis1 (talk) 22:58, 17 August 2014 (UTC) A value is greater, lesser, or equal to the node, it can't be a combination, so effectively there can't be duplicates. If these rules are broken then the invariant associated with the bst breaks. You can effectively think of a bst as a concrete implementation of the abstract data type Set.

isBST method code
The code checks the validity of BST is, in my opinion, wrong. At least, clarification should be added. First, I think rightData & leftData are always MinValue & MaxValue (respectively), instead of changing and checking all the nodes across the tree. Second, it seems like these fields should be vice versa (i.e, the right should be left and vice versa). 06:41, 9 July 2014 (UTC)


 * I was thinking the same thing, and am glad to see I'm not the only one. I'll look into it more. Huttarl (talk) 21:05, 19 July 2014 (UTC)

Comparisons and the "less-than function"
The Operations section states:


 * A common comparator is the less-than function

This sentence, and the paragraph it appears in, suffer from a rather unfortunate choice of concepts to explain orders and comparisons. Making a distinction between less-than and comparison functions is language-specific; in languages with operator overloading, it can lead to circular definitions because less-than in fact has to be implemented in terms of what this paragraph calls a "comparator". I'd rather we skip the notion of a comparator and just introduce <, > as notation for some type/problem-specific ordering. Q VVERTYVS (hm?) 10:36, 10 February 2015 (UTC)

Bulk operations
I've been wanting to write something about this, but couldn't get my sources together, so I'll dump my thoughts here for now in the hopes that others can help. It is possible to implement the insert, delete and lookup operations in terms of two helper routines:


 * split(T, k) splits a tree into two trees L and R, where L contains all keys in T less than k and R all keys greater than T (with k itself assigned to L, or R, or neither).
 * join(L, R) merges two trees; it may assume all keys in L are less than all keys in R.

With these, it is also possible to implement union, intersection and set difference much more efficiently than by just running repeated insertions, lookups and deletions.

Sources so far:
 * http://www.parallel-algorithms-book.com/ (unpublished book draft)
 * Mehlhorn and Sanders, Algorithms and Data Structures: The Basic Toolbox p. 157-158 (brief sketch of the split operation)

Q VVERTYVS (hm?) 11:09, 10 February 2015 (UTC)


 * To be sure, I'm not talking about the naive join algorithm that you can find on various places on the web, which takes O(n + m) time (turn L into a list, turn R into a list, turn list back into a BST). The problem is apparently solvable in O(log m + n) time, which means implementing insertion in terms of join is feasible. Q VVERTYVS (hm?) 16:51, 10 February 2015 (UTC)


 * Ok, found it. These operations are commonly associated with treaps and discussed in, e.g., this paper. I'm not sure if adding them to this article makes much sense. Q VVERTYVS (hm?) 11:12, 12 February 2015 (UTC)

TreeNode
The symbol TreeNode is used in the article twice in different sense. In the first case it is used as a subroutine with 4 arguments in subroutine binary_tree_insert without a definition. The second case is a struct defined in Binary search tree. --Nomen4Omen (talk) 20:04, 3 November 2015 (UTC)

Types
There appears to be some differences in the introduction and the other sections of the article relating to balancing. From my reading the article seems that both balanced and unbalanced are claimed. I may have read it wrong.

Introduction
From the introduction: "They are a special case of the more general B-tree with order equal to two."
 * Can be omitted. History went BST --> self-balancing tree --> B-tree. So the generalization to orders > 2 took with it the self-balancing property. This is best explained at B-tree and not at BST. --Nomen4Omen (talk) 16:53, 4 November 2015 (UTC)

B-tree
From the B-Tree article: "In computer science, a B-tree is a self-balancing tree data structure ..."
 * Conflict disappears after previous edit. --Nomen4Omen (talk) 16:53, 4 November 2015 (UTC)

Types
From the Types section: "Two other titles describing binary search trees are that of a complete and degenerate tree." and then "A degenerate tree is a tree where for each parent node, there is only one associated child node. It is unbalanced and, in the worst case, performance degrades to that of a linked list." Jonnypurgatory (talk)
 * The article describes BSTs. These are NOT NECESSARILY balanced, they MAY be balanced. The balanced resp. self-balancing trees are the more interesting ones, but of course they have properties with BSTs in common. --Nomen4Omen (talk) 16:53, 4 November 2015 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 2 external links on Binary search tree. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20141012033537/http://linneus20.ethz.ch:8080/4_7_1.html to http://linneus20.ethz.ch:8080/4_7_1.html
 * Added archive https://web.archive.org/web/20100328221436/http://jdserver.homelinux.org/wiki/Binary_Search_Tree to http://jdserver.homelinux.org/wiki/Binary_Search_Tree

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 15:44, 20 July 2017 (UTC)

Codes
Why are codes in all languages? Some in Python. Some in C++. Sherwilliam (talk) 13:29, 12 October 2019 (UTC)


 * I mean if you want both languages, then program all functions in both. Now half is in python and half in C++. Sherwilliam (talk) 16:15, 12 October 2019 (UTC)

Why empty leaves?
Why do leaves not store keys? It's better to define the leaves as the nodes that have no children, but still store a key. -Pgan002 (talk) 05:15, 3 June 2020 (UTC)


 * In principle good question and remark. But as far as I can see, the use of the terms leaf, internal leaf, external leaf, node carrying a key, node without key differs slightly among the authors Knuth, Sedgewick, Mehlhorn et al and maybe even between AVL and RB of the same author. I propose not to use such a term in the intro or use it with great care. Maybe it is useful to juxtapose two such views early in an article like "BST" (or "BT") and then restrict the terminology throughout the rest of the article(s). - Nomen4Omen (talk) 06:23, 3 June 2020 (UTC)

Python-function NodeTree
Does somebody know a little more about the (undeclared) Python-function "NodeTree(None, key, value, None)" in the section Binary search tree? Maybe even insert a code snippet? The purpose should be to show an example of a persistent data structure. - Nomen4Omen (talk) 18:41, 5 June 2020 (UTC)

search_duplicatesAllowed always returns None
while-loop condition is 'current_node != None', and this is the only case to exit the loop.


 * You are right: needed are 2 variables. I tried to improve, but do not know Python very well. Would you pls look at it? −Nomen4Omen (talk) 07:30, 19 April 2021 (UTC)

Changes of as of 30 July 2021
[Section moved from User_talk:WikiLinuz to here, so that other users who are interested in the article can participate in the discussion more easily.] ― on 31 July 2021

In my opinion some of your additions to Binary search tree are completely misplaced, so I'm thinking of throwing them out:

The sentence begins "Deleting a node D with two children:" from this it is clear that D has a left and a right subtree. This means that your lengthy footnotes about predecessor and successor are extremely pointless. ―Nomen4Omen (talk) 08:27, 30 July 2021 (UTC)
 * There is no implementation and "proper" explanation of the actual process of finding the in-order pred/successor on the article. The diagram merely explains the actual process of deleting the node and limited to a single case. The explanation below the image is too vague for one to implement. There neither exists actual code example which explains/supports the explanation and various cases/caveats involved nor disambiguous explanation of various cases. So, I don't find any reason to "throw them out". WikiLinuz (talk) 08:51, 30 July 2021 (UTC)


 * I assume that you saw the title "Deletion" of the section. You try to tell me that «there is no implementation and "proper" explanation of the actual process of finding the in-order pred/successor on the article.» This may be true, but is another issue. In the present context of deletion there is no need to explain the general «process of finding the in-order pred/successor» (only the «actual» i.e. restricted to deletion) and your 2 footnotes are much too thick: e.g. the snippet  is sufficient which btw. resembles very much your Case 1. Your Case 2 is totally superfluous in the deletion context.
 * Of course, it's up to you to insert an «implementation and "proper" explanation of the actual process of finding the in-order pred/successor». But please choose another section for doing that. ―Nomen4Omen (talk) 17:03, 30 July 2021 (UTC)


 * Which another section are you talking about? Do you want me to create a new sub-section which is dedicated for the notes with all the cases? If you meant that, I've thought of doing that but, the process of finding in-order pred/successor is specific to deletion in BST, so I don't think it best fits the format of the current article. The cases and explanation as a note, like it is on the current version, is good enough. I don't think any modification to the placement of the note is necessary. WikiLinuz (talk) 17:46, 30 July 2021 (UTC)


 * It is not me to think or talk about another section. This is totally and absolutely your issue: You are introducing contents which is not appropriate to the section. After having introduced this horribly sophisticated code, it should be no problem for you to find an appropriate place for it. ―Nomen4Omen (talk) 09:54, 31 July 2021 (UTC)


 * There is absolutely no need for the content to be removed. You did not provide a valid reason. DO NOT revert valid edits. I've clearly informed, in plain English, to you about why the note has to be presented there, since it lacks the explanation. DO NOT touch my edits, since you don't have any valid points to present. —— WikiLinuz (talk) 13:26, 1 August 2021 (UTC)

The explanation of my reverts (all of them I consider valid) of your edits is already in this talk. But as you seem to have problems with reading, I repeat:
 * 1) Not I was beginning to revert, but you.
 * 2) Furthermore, your footnotes are misplaced, as I tried to explain in this talk. I said (09:54, 31 July 2021 (UTC) above) that “You are introducing contents which is not appropriate to the section.”
 * 3) You gave in by yourselves (17:46, 30 July 2021 (UTC) above) that you «thought of doing that (i.e. creating a new sub-section) but, the process of finding in-order pred/successor is specific to deletion» ― a statement which is not true. (And after doubting, you now say «I've clearly informed, in plain English, to you about why the note has to be presented there». But the doubt is justified.)
 * 4) Namely, finding in-order pred/successor is in-order traversing. And there is indeed the article Tree traversal containing several sections about in-order traversal and pred/successor. And this is the true place where the subject belongs to. And there had existed a link to one of these sections which you have thrown out with the remark «rm unwanted linkage;».
 * 5) I gave you the chance to enter a section for your in-order pred/successor subject from 09:54, 31 July 2021‎ where you have been active 12:37 and 23:49, 31 July 2021 without answering, so I reverted your footnotes 09:38, 1 August 2021 without a loss of information as far as the article is concerned.

By the way, it is terribly misleading to the readers to name both Cases 1 and 2  resp. !!! What shall a user do with this intentionally ambiguous information??? And as already mentioned above, the 2 Case 2 footnotes have nothing to do with deletion. Moreover, they are of really bad quality in that they refer to the node’s key which can (and should!) be avoided as shown in Tree_traversal.

So, under observation of the WP-rules I do not intend to tolerate your deterioration of the article. ―Nomen4Omen (talk) 15:38, 1 August 2021 (UTC)

And for these reasons, the footnote doesn't deteriorate the article, so I didn't violate any of WP's rules like you mentioned. —WikiLinuz (talk) 16:55, 1 August 2021 (UTC)
 * 1) I don't understand why you mean by you was not beginning to revert. You clearly reverted the note edits. See 9 edits of revert from [|here]
 * 2) Why are you saying that it's misplaced? It's placed in the specific section where the discussion of in-order successor and predecessor comes in. And in the case of BST, finding in-order predecessor and successor is specific to the process of deletion. So, the note explaining various caveats or specific cases is placed in such a location.
 * 3) I was specifying that point, because explaining various cases involved in finding the in-order predecessor and successor is a step *within* the deletion process. Because, it is in the deletion that one needs to find those nodes. So, since it's within the process of deletion, having a footnote which mentions the cases in the deletion subsection is appropriate, since the explanation doesn't need a separate sub section or a separate article for the reasons I mentioned.
 * 4) Finding in-order successor and predecessor is not just in-order traversal. That is incorrect. If you're in an arbitrary location/node in a BST, and you wanna find the in-order successor or predecessor of the current node, unless you have an array or map of all the nodes in in-order fashion which you've pre-traversed and stored in some location(which is horribly inefficient), you cannot find in-order predecessor or successor. You must have to follow the step that are specified on the footnote. And following the process have two caveats like mentioned on the note.
 * 5) Like I mentioned on point 3, the reason why anyone wanna find an in-order successor or a predecessor of a current node is in the process of deletion. So, it has to be within the deletion process. And having a minimal footnote in the right place where the discussion of finding in-order predecessor and successor is, as per the format of the current article, the appropriate thing to do. Which doesn't clutter the deletion subsection, since it's kept as a footnote.
 * 6) And there indeed two cases which the original article doesn't cover. Because the the reasons I mentioned on the notes. You cannot find the predecessor of a node with just case one. There are two cases involved in finding the in-order predecessor. And same applies to the successor.


 * My reply:
 * To your 1: You mention my edit 09:16, 1 August 2021. But you started reverting, as I already mentioned above, on 06:07, 30 July 2021‎ (rm unwanted linkage;). Moreover, this is a very important link, because it gives you the hint to in-order predecessor and successor. But you only say «rm unwanted linkage;».
 * To your 2: I said above 08:27, 30 July 2021: “The sentence begins "Deleting a node D with two children:" from this it is clear that D has a left and a right subtree.” So the Cases 2 which address nodes without children, are misplaced in this context.
 * To your 3: I agree «finding the in-order predecessor and or successor is a step *within* the deletion process» (btw., one of the two is good enough ― and had been addressed by the link you threw out). But the Cases 2 do not occur with deletion, although with traversal. So these cases are inappropriate as I said.
 * To your 4: As pointed out in Tree_traversal iterativeInorderUpwards, it IS possible to find in-order predecessor or successor. It is NOT necessary «to follow the step that are specified on the footnote». (And it can be done in $$\mathcal{O}(h)$$.)
 * To your 5: Small objection to «the reason why anyone wanna find an in-order successor or a predecessor of a current node is in the process of deletion». This idea is due to T.N. Hibbard and is a good one. But there are also other solutions.
 * To your 6: I do not exactly know what you mean by «indeed two cases which the original article doesn't cover». But, if you mean your Cases 2, then here is indeed NO NEED to cover them in the given context of deletion, as already said earlier and again in To your 3. These Cases 2 are to be handled with traversal, as already said.
 * To your 7: I did NOT say that you «violate any of WP's rules like you mentioned». I said: “So, under observation of the WP-rules I do not intend to tolerate your deterioration of the article.” In summary, I'm not sure what you read and what you understand.


 * By the way, I had a short look into your function Case_2..
 * How does  get into the function?
 * If, then   and   appear undefined to me. So the function crashes.
 * Best regards, ―Nomen4Omen (talk) 19:13, 1 August 2021 (UTC)


 * 1) The   on my specific code is supposed to be specified by the user and it's an implementation detail. We "assume" that   is a pointer to the root node of the BST, and leave it to the user to implement such a detail.
 * 2) You are correct,   is supposed to be replaced with  . That is a typo from my part.

And regarding you mention of "one of those are good enough", that isn't the point of a Wikipedia article. You mention both, in-order successor and predecessor in the article and explain the caveats/cases, implement one of the two on the code part of the article, and leave it to the user to choose, either in-order successor or predecessor on *their* implementation, without having to restrict a user/reader to "one specific method" and "one specific case from a diagram". —WikiLinuz (talk) 19:45, 1 August 2021 (UTC)

Changes on 16 Aug 2021​
–Nomen4Omen (talk) 08:25, 16 August 2021 (UTC)
 * 1) Ordering R/O-operations together before R/W-operations Insertion, Deletion.
 * 2) in-order ===> inorder
 * 3) Introduction of the ancestor stack (as part of a "traverser")
 * 4) New section "Advancing to the next or previous node" as a piecewise kind of traversal, well suited to iterative programming
 * 5) Insertion after some iterative search

Contributions of 134.19.119.156 on 17 Aug
[Obviously, we are both observers of the article Binary search tree.]

Indeed, user 134.19.119.156 is absolutely right in assessing your Case 2 footnotes as inferior compared to my Part B in section Binary search tree at least wrt. efficiency. It is easy to see that –at least for balanced trees (which are the important cases)– your Case 2 has an average performance of O(h)=O(log n) whereas mine has O(1).

So your two Case 2 footnotes have at least two drawbacks:
 * 1) Misplacement in section Deletion (as already pointed out in the talk page above)
 * 2) Bad performance

So it would really be interesting where you see the «superiority» as you have remarked in your edit summary. And I am expecting an answer. –Nomen4Omen (talk) 17:08, 17 August 2021 (UTC)
 * The 'superiority' comes in because your code is too messy for the page. I mean, I don't think you did a peer-review of the contribution before making such a larger changes. You must cleanup the code that you've submitted. Compared to the mess, the code I submitted is 'straightforward'. And it is not misplaced. Because, like I already mentioned, the only place where you'd need to find and check against those cases is on deletion. And the user  is a possible WP:SOCK. —WikiLinuz (talk) 01:58, 18 August 2021 (UTC)

Did you explain why it is «unwanted» or isn't it just you single only who does not «want» it? It was a link to another article which was explaining suc/predecessor and navigating from a node backward or forward. A navigating sample which I imported in C shape into the section "Advancing to the next or previous node".
 * At least, there is a reaction. Thanks!
 * But there are still questions:
 * What do you mean by «too messy»? Too many lines?
 * Is it less messy to have lengthy footnotes?
 * Did you do a peer-review before your «rm unwanted linkage;» on 6:07 30 July ?
 * You say your code is «straightforward»! I admit, your Cases 1 are straightforward. But they are essentially the same as the Python sample  directly below which has been in the article prior to your Cases 1.
 * Is it straightforward to give two different functions the same name ? What shall the reader think about such a naming? Do these functions do the same? (Same question for  )
 * Is it straightforward to enter code samples with inferior performance?
 * Did you give a source for your strange proposals?
 * Indeed: you already mentioned «the only place where you'd need to find and check against those cases is on deletion». But you are totally wrong with this statement. The source I give (Ben Pfaff) gives his code piece almost the same name, namely "Advancing to the Next Node". It is very common e.g. in connection with data bases to start at a certain key and then advance (search) sequentially from this on for a possible final result. Why do you insist to suppress this more general view of piecemeal navigation or traversal? (Ben Pfaff spends a chapter to it!)
 * Your Cases 2 are never needed in the context of deletion (they are misplaced as I say).
 * Your Cases 2 require knowledge of key and comparison function which is NOT needed by the alternative.
 * Your Cases 2 do not work when duplicates are allowed in the tree, whereas the alternative does.
 * Your Cases 2 have worse performance, because they always start from the tree's root (highest level), whereas the alternative mainly navigates in the levels close to the leaves where the big majority of nodes are.
 * What do you mean by your strange comment «using case 2’s traversal technique»? Isn't then simple end-of-navigation (which has to happen some time and which has to be told to the user)?
 * User 134.19.119.156 was right in detecting the redundancy (superfluousness) of your footnotes in that version and in removing them.
 * –Nomen4Omen (talk) 08:40, 18 August 2021 (UTC)


 * You've to first contribute clean code if you want the readers to understand what you're trying to convey, the code that you've provided is 'ugly'. If you disagree, compare your version to that of other articles. By performance, have you looked into the space complexity of your solution? You must consider and explicitly mention the space complexity of the solution when you're submitting a specialized code, a specific kind of traversal method. There are always trade-offs when there are multiple implementations. There are also multiple grammatical errors on your contribution, which makes it really confusing to grasp. Clean up your code, and make it 'non-ugly', expand the acronyms, and explicitly mention about the space complexity of your solution, not just 'time'. On my code sample, it's pretty standard method of implementation. If you're only talking about 'performance', obviously, there are multiple other ways to gain much higher performance than the code that you've provided, but that'd just take higher space, just like yours. And my code sample explicitly deals with finding inorder pred/succ in a more generalized case, not compared to yours which is highly specialized and deeply coupled to one specific type of traversal that depends on internal members. That isn't what generalization means. Given that, there isn't any need for generalized samples to be taken out. —WikiLinuz (talk) 13:40, 18 August 2021 (UTC)

Request for 3O
On 19 Aug 2021 user:Nomen4Omen had entered the following line into WP:Third opinion:

# Talk:Binary_search_tree. Disagreement about placement and naming of functions and since yesterday about 'ugliness'. 07:33, 19 August 2021 (UTC)

–Nomen4Omen (talk) 13:47, 23 August 2021 (UTC)

Source Addition
There's this helpful site called visualgo.net that includes helpful demonstrations and interactive examples of computer science concepts, including the binary search tree. Could someone please add this as a source? ScientistBuilder (talk) 21:45, 13 October 2021 (UTC)ScientistBuilderScientistBuilder (talk) 21:45, 13 October 2021 (UTC)
 * Added the site as one of the external links in this revision diff. add this as a source, book by Steven Halim passes WP:RS/SPS and the media can be used on Wikipedia since the site effectively states CC-BY on its ToS. WikiLinuz  ( talk ) 22:30, 13 October 2021 (UTC)


 * That site was aggressively spammed a few years ago and duplicates material we already have. I took it back out. - MrOllie (talk) 22:33, 13 October 2021 (UTC)
 * aggressively spammed? Could you link me to that? I don't know about that event. WikiLinuz  ( talk ) 22:36, 13 October 2021 (UTC)
 * An IP added it to a couple dozen articles, I don't have anything specific to link to about it. - MrOllie (talk) 22:40, 13 October 2021 (UTC)
 * To mention, there is also a notable site hosted by Stanford University department which we use on BST visualization as an external link on few articles. Given this is written by an academic, I seriously doubt that it's aggressively spammed. WikiLinuz  ( talk ) 22:42, 13 October 2021 (UTC)
 * People spam links for all sorts of reasons. Ego is as powerful a motive as profit. But at any rate we already have a link that provides the same sort of content. - MrOllie (talk) 22:44, 13 October 2021 (UTC)
 * There's a difference between spamming and linking to a resource hosted by an academic or a university's department on articles. In the later case, a link added of good faith, effectively passes WP:ELNO #11 for the reasons mentioned. It's only WP:LINKSTOAVOID if there it's some promotional website which is trying to attract traffic or outright irrelevant. Also, if we already have a link that provides the same sort of content, we give WP:DUE to the best one, which should be ranked objectively. WikiLinuz  ( talk ) 22:54, 13 October 2021 (UTC)
 * I'm not saying you're spamming it, but when a link is previously spammed, and we already have another link that is much the same thing, it is a factor in which one we should keep. We really don't need duplicates. MrOllie (talk) 23:08, 13 October 2021 (UTC)
 * 1 is clearly better than currently existing 2 if we visit and use it. Given that, I'm inclined towards replacing it with the better one if it seems like duplicates. WikiLinuz  ( talk ) 23:13, 13 October 2021 (UTC)
 * I've already objectively mentioned why that link should be added on my previous comments. If you WP:JUSTDONTLIKEIT, explain me here. Do not play revert wars. You don't seem to support your claims of the link being previous spammed through evidence. Prove me wrong if you wanted to keep the previous link, if you're not gonna do that, I'll revert this diff. WikiLinuz  ( talk ) 09:24, 14 October 2021 (UTC)
 * Your argument, conversely, is just ILIKEIT. Other people frequent this talk page, at this point I think it is best to maintain the status quo ante bellum until one of them chimes in. Accusing me of playing revert wars while simultaneously pledging to revert war yourself is rather inconsistent, you might want to think about it. - MrOllie (talk) 11:27, 14 October 2021 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion
The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion: Participate in the deletion discussion at the. —Community Tech bot (talk) 16:52, 22 December 2022 (UTC)
 * Binary search tree deletion illustration.png