Talk:K-d tree

message: I believe the explanations on the animation are incorrect. The search is not always "first left then right". Instead, the component of the search vector that corresponds to the split dimension at the current node is compared to that stored in the node. This decides the direction of the search (either left of right). 85.23.56.103 (talk) 14:12, 18 January 2011 (UTC)
replies: text: 1) Its left or right in tree space, not real-space. This tree space would correspond to the "upper" and "lower" sides of the split plane, if you prefer. 2) you can select by variance, but this makes your traversal algorithms slower, as you cannot simply compute the axis from the tree depth -- you have to retrieve it as it may be altered. Its also slower to construct because you have to check the variance. However, the search may be slightly faster due to  "zeroing in" on the target quicker, IFF your data has strong spatial correlations. This is OR, and would also be a needless complication of the algorithm presentation. 129.67.86.189 (talk) 20:28, 13 May 2011 (UTC)
replies: text: Left and right is absolutely in tree space and thus arbitrary. While finding the variance or range does make building the tree slower the entire benefit of a KD tree structure is that you build it up front and then reference it repeatedly. In practical terms this means that it is almost always a better idea to split along the axis of greatest variance/range than to hurt search performance (because additional useless splits really hurt search performance). I've written several algorithms based on KD-trees and have seen that there are also some provable positive aspects to splitting on the axis of greatest range in terms of how many traversals a nearest neighbor will be away in the tree. Any time you have data that is not evenly distributed you get a significant boost by splitting intelligently. Adam McCormick (talk) 05:32, 18 May 2011 (UTC)
thread_title:  Opening heading 

message: Articles suggests that a k-d tree can be used to store space-consuming objects (e.g. rectangles, in 2 dimensions) but only specifies how this affects the range search algorithm.  It would be useful to expand this to cover other algorithms (especially construction, but nearest-neighbour would probably be useful, too). JulesH (talk) 14:04, 7 September 2013 (UTC)
thread_title:  k-d tree for space-consuming objects 

message: The pseudocode for the tree construction is missing the trivial case (I assume, where there are no points, or one point).  Something like "if more than one point then ..." around creating the subtrees?  — Preceding unsigned comment added by 67.159.132.225 (talk) 05:58, 30 January 2014 (UTC)
thread_title:  Error in pseudocode for tree construction? 

message: I find the description of the construction algorithm a bit confusing.
Splitting an array into subarrays - testing against the "x-coordinate", I assume the intent is to test against the current splitting dimension.
Since the array is already sorted, there's no need to "consider each element of the array" and test x-coordinate against the splitting plane. Instead, just find the median as described later?
The section addressing re-using the arrays, and building the subarrays from k-1 into the k-2 array does not specify whether to do all of this for every depth level, or part of it for every dimensional increase.
In the end it says:
"Hence, building the entire k-d tree requires less than O([k-1]n log n) time, which is less than the O(kn log n) time that is required to sort the n points in k dimensions prior to building the k-d tree."
But the whole premise on which the text describes the algorithm is that the all the k arrays are sorted according to its dimension before building the kd tree, and all the preceding text assumes that they are, so this last sentence does not seem to make any sense.  — Preceding unsigned comment added by Waperboy (talk • contribs) 13:49, 27 September 2014 (UTC)
replies: text: Worse than that is false claim that O([k-1]n log n) is less than O(kn log n); these are the same; see Big O notation.  I think it just means that the total complexity is still O(kn log n), since each of the two major steps is O(kn log n). But I haven't checked it carefully.  A source would be nice for this.  I don't see what the factor of [k-1] is from in "This tree-building algorithm requires at most O([k-1]n) tests of coordinates against splitting planes to build each of the log n levels of a balanced k-d tree. "  Dicklyon (talk) 01:28, 28 September 2014 (UTC)

text: Rather than code, what would be most useful would be a reference to a published source.  And maybe an indication of what you would put (k-1) instead of k in a big-O notation.  Dicklyon (talk) 03:35, 14 October 2014 (UTC)
thread_title:  Construction 

message: I found this link on Hackers News. • Sbmeirow • Talk • 21:52, 25 December 2015 (UTC)
thread_title:  link 

message: Some sources says that "The two main differences between a kD tree and a bst are 1) Values are always stored in leaves, and ...", in the article values are stored in vertices too, should this be clarified?  — Preceding unsigned comment added by VirtualSatai (talk • contribs) 10:12, 5 June 2016 (UTC)
thread_title:  Storing information in nodes + leaves or only leaves 

message: The article says to first search as far as a leaf node, then set the "current best" to that node. The animation does the opposite, first setting the "current best" to the root. This is confusing.  — Preceding unsigned comment added by 137.122.114.44 (talk) 17:17, 9 March 2018 (UTC)
replies: text: The current animation is really confusing - there is no representation of the tree, and there is no explanation of what is going on. There was an earlier animation that was less flashy, but made more sense. 129.67.86.87 (talk) 23:00, 27 October 2020 (UTC)
thread_title:  nearest neighbour algorithm isn't what is shown in the animation