Difference between revisions of "Talk:Kd-tree"
(→Bucket PR k-d tree: kd-tree vs brute force) |
(only perfect tree) |
||
Line 38: | Line 38: | ||
:: Really? I'd be extremely surprised if Simonton's kd-tree had a bug in it. Maybe it's your linear search that has a bug instead (or also)? But I can say with 100% certainty that a kd-tree nearest neighbors search should produce the exact same results as a brute force nearest neighbors search. --[[User:Voidious|Voidious]] 15:01, 16 August 2009 (UTC) | :: Really? I'd be extremely surprised if Simonton's kd-tree had a bug in it. Maybe it's your linear search that has a bug instead (or also)? But I can say with 100% certainty that a kd-tree nearest neighbors search should produce the exact same results as a brute force nearest neighbors search. --[[User:Voidious|Voidious]] 15:01, 16 August 2009 (UTC) | ||
+ | |||
+ | Your tree is the ''only'' tree on this site (exclude Chase-san's tree because it doesn't have k-nearest neighbour search) that is perfect, see this: | ||
+ | <pre> | ||
+ | RESULT << k-nearest neighbours search with flat/linear searching >> | ||
+ | : Used time = 447.54298 x 10^{-3} seconds | ||
+ | : Average adding time = 1.374 x 10^{-6} seconds | ||
+ | : Last node adding time = 2.4440000000000004 x 10^{-6} seconds | ||
+ | : Accuracy = 100% | ||
+ | |||
+ | RESULT << k-nearest neighbours search with Rednaxela's k-d tree >> | ||
+ | : Used time = 1265.16806 x 10^{-3} seconds | ||
+ | : Average adding time = 33.005 x 10^{-6} seconds | ||
+ | : Last node adding time = 19.696 x 10^{-6} seconds | ||
+ | : Accuracy = 86% | ||
+ | |||
+ | RESULT << k-nearest neighbours search with Simonton's Bucket PR k-d tree >> | ||
+ | : Used time = 96.38627 x 10^{-3} seconds | ||
+ | : Average adding time = 3.039 x 10^{-6} seconds | ||
+ | : Last node adding time = 3.423 x 10^{-6} seconds | ||
+ | : Accuracy = 80% | ||
+ | |||
+ | RESULT << k-nearest neighbours search with Nat's Bucket PR k-d tree >> | ||
+ | : Used time = 117.65993 x 10^{-3} seconds | ||
+ | : Average adding time = 3.368 x 10^{-6} seconds | ||
+ | : Last node adding time = 3.282 x 10^{-6} seconds | ||
+ | : Accuracy = 80% | ||
+ | |||
+ | RESULT << k-nearest neighbours search with Voidious' Bucket PR k-d tree >> | ||
+ | : Used time = 90.04413000000001 x 10^{-3} seconds | ||
+ | : Average adding time = 4.639 x 10^{-6} seconds | ||
+ | : Last node adding time = 3.562 x 10^{-6} seconds | ||
+ | : Accuracy = 100% | ||
+ | </pre> | ||
+ | Actually, mine and Simonton's got all answer correct, too, but I have this code in the answer checker: | ||
+ | <pre> | ||
+ | if (Math.abs(linearAnswer[0].getDistance() - currentAnswer[0].getDistance()) > 0.00001) | ||
+ | accuracy *= 0.8; | ||
+ | </pre> | ||
+ | So they decrease to 80%. Above result input data is quite large, ''k'' = 150 with 400000 data points and 15 dimension. Here is result with ''k'' = 5, points = 1000 and 4 dimensions. | ||
+ | <pre> | ||
+ | RESULT << k-nearest neighbours search with flat/linear searching >> | ||
+ | : Used time = 9.28114 x 10^{-3} seconds | ||
+ | : Average adding time = 3.738 x 10^{-6} seconds | ||
+ | : Last node adding time = 7.613 x 10^{-6} seconds | ||
+ | : Accuracy = 100% | ||
+ | |||
+ | RESULT << k-nearest neighbours search with Rednaxela's k-d tree >> | ||
+ | : Used time = 3.67735 x 10^{-3} seconds | ||
+ | : Average adding time = 22.053 x 10^{-6} seconds | ||
+ | : Last node adding time = 65.302 x 10^{-6} seconds | ||
+ | : Accuracy = 60% | ||
+ | |||
+ | RESULT << k-nearest neighbours search with Simonton's Bucket PR k-d tree >> | ||
+ | : Used time = 2.47867 x 10^{-3} seconds | ||
+ | : Average adding time = 8.007 x 10^{-6} seconds | ||
+ | : Last node adding time = 4.959 x 10^{-6} seconds | ||
+ | : Accuracy = 80% | ||
+ | |||
+ | RESULT << k-nearest neighbours search with Nat's Bucket PR k-d tree >> | ||
+ | : Used time = 3.32095 x 10^{-3} seconds | ||
+ | : Average adding time = 5.402 x 10^{-6} seconds | ||
+ | : Last node adding time = 5.238 x 10^{-6} seconds | ||
+ | : Accuracy = 80% | ||
+ | |||
+ | RESULT << k-nearest neighbours search with Voidious' Bucket PR k-d tree >> | ||
+ | : Used time = 0.21316000000000002 x 10^{-3} seconds | ||
+ | : Average adding time = 4.586 x 10^{-6} seconds | ||
+ | : Last node adding time = 3.5620000000000003 x 10^{-6} seconds | ||
+ | : Accuracy = 100% | ||
+ | </pre> | ||
+ | Note [1]: This test suite was completely rewritten. The linear search is quite slow since I just basically Collections.sort() the points.<br /> | ||
+ | Note [2]: My tree is 6-ary tree with 22 buckets, which is the faster combination. The fastest isn't reveal yet that is why I create this test suite » <span style="font-size:0.9em;color:darkgreen;">[[User:Nat|Nat]] | [[User_talk:Nat|Talk]]</span> » 15:35, 16 August 2009 (UTC) |
Revision as of 16:35, 16 August 2009
Bucket PR k-d tree
I think you all know about Bucket PR k-d tree (aka Simonton's tree), right? I'll get directly to my point.
The Bucket PR k-d tree (I'll refer as just a tree from now on) is a binary tree split by the median of the bound, right? I wonder if I make it m-ary tree, let say, Ternary or Quaternary tree instead of just binary? Will it better? » Nat | Talk » 09:12, 15 August 2009 (UTC)
Note, it doesn't by definition have to be split by the median, though the median is usually considered the best place. As far as your second question... it may be better, or it may not. I'm pretty sure it will depend heavily on the implementation details and the data set in question. --Rednaxela 14:51, 15 August 2009 (UTC)
In a binary tree you do 1 comparison to narrow it down to 1/2 the tree (if it's well balanced). In a 3-ary you do (on average) 1.5 comparisons to narrow it to 1/3. 4-ary 2 comparisons for 1/4 of the tree. 1*1/2 = 1.5*1/3 = 2*1/4. They're all theoretically the same. --Simonton 15:33, 15 August 2009 (UTC)
- Also note that with a 4-ary tree it's best to do a binary search at each node, which is pretty much the same thing as going back to a binary tree, except you'd be doing two comparisons for the same dimension instead of stepping to the next. --Simonton 15:36, 15 August 2009 (UTC)
(Edit conflict) It could be faster splitting 4-ways, sure, but my gut says not by very much. I'd probably recommend doing the normal 2-way (binary) one first, since it will be much simpler to develop and to debug, and then you can try to modify it to do 4-way. You'll need the 2-way version, anyway, in order to compare the speeds. Good luck. --Voidious 15:38, 15 August 2009 (UTC)
It seems that Ternary tree is the fastest of binary, ternary and quaternary. But I've some question, does the Kd-Tree output the same as linear (brute-force) search. Some of my test state that:
Starting Bucket PR k-d tree performance test... Generating points... Data generated. Performing linear search... Linear search complete; time = 0.003425156 Performing binary k-d tree search... Binary tree search complete; time = 0.001995574 : accuracy = 0.4666666666666667 Performing ternary k-d tree search... Ternary tree search complete; time = 2.91098E-4 : accuracy = 1.0 Performing quaternary k-d tree search... Quaternary tree search complete; time = 3.22178E-4 : accuracy = 1.0
Data completely random. Accuracy calculate by number of result that is same as linear / cluster size
. This test with a hundred data points and cluster size of 15. If I increase the data points to 26,000 then the accuracy drop to zero. Is this my tree problem or it is known problem with Kd-Tree? » Nat | Talk » 16:34, 15 August 2009 (UTC)
The kd-tree should definitely give the same results as a brute force search, so you must still have some bugs to work out. --Voidious 16:38, 15 August 2009 (UTC)
- Really? Simonton's one sometimes wrong too! » Nat | Talk » 11:28, 16 August 2009 (UTC)
- Well, more test with m-ary tree and Simonton's and it seems that my tree and Simonton's have the exact same output but my linear didn't. I'll try your, Rednaxela's and Chase-san's one before conclude. Expected some kd-tree benchmarks this night (ICT), afternoon (UTC) or morning (EST) » Nat | Talk » 11:56, 16 August 2009 (UTC)
- Really? I'd be extremely surprised if Simonton's kd-tree had a bug in it. Maybe it's your linear search that has a bug instead (or also)? But I can say with 100% certainty that a kd-tree nearest neighbors search should produce the exact same results as a brute force nearest neighbors search. --Voidious 15:01, 16 August 2009 (UTC)
Your tree is the only tree on this site (exclude Chase-san's tree because it doesn't have k-nearest neighbour search) that is perfect, see this:
RESULT << k-nearest neighbours search with flat/linear searching >> : Used time = 447.54298 x 10^{-3} seconds : Average adding time = 1.374 x 10^{-6} seconds : Last node adding time = 2.4440000000000004 x 10^{-6} seconds : Accuracy = 100% RESULT << k-nearest neighbours search with Rednaxela's k-d tree >> : Used time = 1265.16806 x 10^{-3} seconds : Average adding time = 33.005 x 10^{-6} seconds : Last node adding time = 19.696 x 10^{-6} seconds : Accuracy = 86% RESULT << k-nearest neighbours search with Simonton's Bucket PR k-d tree >> : Used time = 96.38627 x 10^{-3} seconds : Average adding time = 3.039 x 10^{-6} seconds : Last node adding time = 3.423 x 10^{-6} seconds : Accuracy = 80% RESULT << k-nearest neighbours search with Nat's Bucket PR k-d tree >> : Used time = 117.65993 x 10^{-3} seconds : Average adding time = 3.368 x 10^{-6} seconds : Last node adding time = 3.282 x 10^{-6} seconds : Accuracy = 80% RESULT << k-nearest neighbours search with Voidious' Bucket PR k-d tree >> : Used time = 90.04413000000001 x 10^{-3} seconds : Average adding time = 4.639 x 10^{-6} seconds : Last node adding time = 3.562 x 10^{-6} seconds : Accuracy = 100%
Actually, mine and Simonton's got all answer correct, too, but I have this code in the answer checker:
if (Math.abs(linearAnswer[0].getDistance() - currentAnswer[0].getDistance()) > 0.00001) accuracy *= 0.8;
So they decrease to 80%. Above result input data is quite large, k = 150 with 400000 data points and 15 dimension. Here is result with k = 5, points = 1000 and 4 dimensions.
RESULT << k-nearest neighbours search with flat/linear searching >> : Used time = 9.28114 x 10^{-3} seconds : Average adding time = 3.738 x 10^{-6} seconds : Last node adding time = 7.613 x 10^{-6} seconds : Accuracy = 100% RESULT << k-nearest neighbours search with Rednaxela's k-d tree >> : Used time = 3.67735 x 10^{-3} seconds : Average adding time = 22.053 x 10^{-6} seconds : Last node adding time = 65.302 x 10^{-6} seconds : Accuracy = 60% RESULT << k-nearest neighbours search with Simonton's Bucket PR k-d tree >> : Used time = 2.47867 x 10^{-3} seconds : Average adding time = 8.007 x 10^{-6} seconds : Last node adding time = 4.959 x 10^{-6} seconds : Accuracy = 80% RESULT << k-nearest neighbours search with Nat's Bucket PR k-d tree >> : Used time = 3.32095 x 10^{-3} seconds : Average adding time = 5.402 x 10^{-6} seconds : Last node adding time = 5.238 x 10^{-6} seconds : Accuracy = 80% RESULT << k-nearest neighbours search with Voidious' Bucket PR k-d tree >> : Used time = 0.21316000000000002 x 10^{-3} seconds : Average adding time = 4.586 x 10^{-6} seconds : Last node adding time = 3.5620000000000003 x 10^{-6} seconds : Accuracy = 100%
Note [1]: This test suite was completely rewritten. The linear search is quite slow since I just basically Collections.sort() the points.
Note [2]: My tree is 6-ary tree with 22 buckets, which is the faster combination. The fastest isn't reveal yet that is why I create this test suite » Nat | Talk » 15:35, 16 August 2009 (UTC)