Talk:Selection algorithm

message: No where on the page is the min-max heap mentioned, which is also a valid deterministic linear time solution to find the kth smallest (or largest) element in a list. It uses the linear time selection algorithm to build the min-max-median heap though. — Preceding unsigned comment added by Dhruvbird (talk • contribs) 15:30, 21 October 2012 (UTC)
thread_title:  No mention of min-max heap as a linear time selection algorithm 

message: lols, median might b found in linear time, recursively, assuming we got the solution 4 a smaller group, 4 median, n use this result etc... :P 4 ur delite  — Preceding unsigned comment added by 93.118.212.31 (talk) 12:34, 27 July 2011 (UTC)
replies: text: Select is then called recursively on this sublist of n/5 elements to find their true median.
Since Select does not find the true median of the n elements, it does not find the true median of the n/5 elements in the general case. It would be more appropriate to call this value the "pivot" or "approximate median". Philippe.beaudoin (talk) 20:47, 5 April 2011 (UTC)
thread_title:  ''Select'' does not find the true median! 

message: I know it is not arbitrary chosen, but I cannot any article backing this up. If somebody would know why we can add it to the contents of this page.  —Preceding unsigned comment added by 145.120.14.117 (talk) 21:21, 27 January 2011 (UTC)
thread_title:  Why is a group size of 5 used? 

message: "By using non-strict comparisons (<= and >=) instead, we would find the minimum element with maximum index; this approach also has some small performance benefits."  What performance benefits, exactly?
:On some machines it can cause less branch instructions, and so generate less icache flushes. The loop also has to have been unrolled or have other unconditional instructions in it. This effect is so small and machine-dependent however that I'll go ahead and remove this claim. Deco 02:08, 24 November 2005 (UTC)
thread_title:  Benefit of Non-strict Comparisons 

message: Shouldn't the quicksortOnlyFirstK pseudocall call itsself instead of quicksort, or am I missing something obvious.--ISee 07:22, 26 April 2006 (UTC)
replies: text: Fixed that after verifying that part of the algorithm--ISee 11:10, 26 April 2006 (UTC)
thread_title:  quicksortOnlyFirstK not recursive? 

message: or perhaps the swap line was correct, but a the end of partition you need to swap a[right] back to a position between the two subsegments...
mwb
:Yes... that line was there. Someone just removed it and introduced several other errors. I've reverted them. Deco 23:21, 11 October 2006 (UTC)
thread_title:  correction 

message: I don't understand why the index of the minimum/maximum element seen so far is stored in the described algorithm. In the example pseudocode, it is not used for anything. Ahy1 12:05, 29 December 2006 (UTC)
replies: text: It's part of the result. Often you want not only the minimum/maximum value, but the index at which it occurred, for later processing. Deco 14:50, 29 December 2006 (UTC)
thread_title:  Linear minimum/maximum algorithms 

message: A selection algorithm is not only for finding the kth smallest (or kth largest) number in a list. In Genetic algorithms they use other shemes for selection than the smallest value for example. Or in real-time/embedded systems there exists selection algorithms, that just take a msg and take an action according to the type of message. So it isn't all about finding the smallest values...
:These are just different things with the same name. I'll clarify that the term use here is specialized. Dcoetzee 00:08, 5 May 2007 (UTC)
thread_title: Remarks

message: There is a variation of selection that David Musser refers to.
Introselect has an analogous relationship to quickselect that Intrasort has to quicksort - all designed to ensure both average and worse-case performance of O(n). But Musser in his paper does not say what algorithm would be swopped to if quickselect goes bad. 
I think this page should to refer to Introselect.
There is also another variation of finding the kth of n elements - where the elements remain undisturbed. Naturally the overhead is considerably higher and I dont know what the average big-O performance is like. [User:Stephen Howe|Stephen Howe] 21:50, 4 May 2007 (UTC)
replies: text: Good idea, introselect ought to be mentioned. Dcoetzee 00:08, 5 May 2007 (UTC)
thread_title:  Introselect 

message: In the selection function, shouldn't we compare pivotNewIndex - left + 1 with k, which means selection of kth smallest number in list(left:right).
:I don't think so, you have to think of it as shrinking the target area around k, which remains relative to the whole array.--Sam Brightman (talk) 16:14, 7 January 2009 (UTC)
thread_title:  Error? 

message: Section : Repeated application of simple selection algorithms
O(n) to select k-th element. O(n) to compare all elements to it.  —Preceding unsigned comment added by 132.72.98.166 (talk) 13:03, 12 November 2007 (UTC)
replies: text: No, it's O(kn), because it can't just magically pick out the kth smallest element on the first try - it has to first identify each smaller element. Dcoetzee 13:26, 12 November 2007 (UTC)
replies: text: Read the article you are commenting on, and it'll show you a great "magical" algorithm for choosing the k-th smallest element in linear time. The GP is correct, it requires only O(n) time to choose the k smallest elements. 142.20.202.196 (talk) 16:49, 25 January 2011 (UTC)
thread_title:  primitive algorithm to select k elements - O(n) not O(kn)  

message: One of the advantages is claimed to be "after locating the jth smallest element, it requires only O(j + (k-j)2) time to find the kth smallest element, or only O(k) for k ≤ j".
I didn't understand this part. Suppose we've found the minimum (j=1), and we are going to find the second smallest element (k=2). Can we find it in O(1) time?  —Preceding unsigned comment added by Roy hu (talk • 
contribs) 22:50, 22 January 2009 (UTC)
thread_title:  Question regarding the nonlinear general selection algorithm 

message: The proof of O(n) running time for the linear general selection algorithm implicitly assumes all elements are different (with the given partition and select function)
Indeed, when running with a series of n equal elements with the given partition and select function, this algorithm runs in O(n**2). I guess the following fix would be ok : partition should put all elements equal to the pivot together, and return two indexes i and j such that list[i], list[i+1], ..., list[j] are equal to the pivot,
and all elements before i are smaller (not just smaller or equal) than the pivot and all elements after j are greater (not just greater or equal). Then select has to check whether the k-th value is before i, after j or between them.
(I have no access to Musser's article to check what he says about this)
Judicael (talk) 09:46, 4 January 2010 (UTC)
thread_title:  Bug in linear general selection algorithm 

message: I am trying to implement this algorithm and find a problem with this line:
             quicksortFirstK(list, pivotNewIndex+1, right, k-pivotNewIndex)
I believe it should  be 
             quicksortFirstK(list, pivotNewIndex+1, right, k)
Reasoning:
Our index which we are sorting to should never change. By doing k - pivotNewIndex we change that index. 
I believe the intent of the author who put this algorithm in here was to change it so that the first k indexes AFTER left (which now equals pivotNewIndex+1 and so this k would then make sense) rather than the absolute k. In order for this assumption to be true you would have to change the if statement to if pivotNewIndex - left < k. This change could also fix the algorithm, but would be slower and less clear.
I have it implemented it in java and it will not work correctly until I set that and it works perfect (no excessive sorting above k) with it set how I have it fixed.
You are correct.  The "k-pivotNewIndex" would be correct for a function that always took a modified "list" pointer and a "left" boundary being always zero.  I've updated the main page.  --bcwhite  —Preceding unsigned comment added by Bcwhite (talk • contribs) 18:15, 29 June 2010 (UTC)
thread_title:  Bug in quicksortOnlyFirstK 

message: hi, i think main idea abt this algo could lead us to a linear time, evn for the worst case, by 
considerring 2 groups of 4 pivots, 2 from each group (2 groups of 2 pivots n produce the next 2 pivots 4 the group-double) . i think in this current configuration, BFPRT median of medians looks more like N^(log_5(3)) guard assured which is not linear (worst case not linear) Florin Matei,Romania 93.118.212.93 (talk) 04:51, 9 October 2012 (UTC)
replies: text: The writing is just confusing - somebody jumbled it up pretty bad since I originally wrote it. BFPRT (the same thing as the "median-of-median" algorithm) is indeed worst-case linear, as you can easily verify by reading the abstract of the paper cited. But the section "partition-based general selection algorithm" describes quickselect, the algorithm it is based on, which is expected-time linear and worst-case quadratic. Dcoetzee 10:00, 19 July 2010 (UTC)
thread_title:  BFPRT Worst Case O(n) or Not? 

message: if pivotNewIndex < k // questionable
             findFirstK(list, pivotNewIndex+1, right, k)
This code is listed in the article. If pivotNewIdex is among the first K items, then we need to return the left partition ie list[left..pivotNewIndex-1] because these elements are definitely among the smallest K items. Then, we need to recur on the right partition but with a reduced value for k. If we initially wanted k=1000 items, now we just want 950 items if the left partition already provides the smallest 50 items.
The algorithm as is could crash if k exceeds the range ie K > (right - pivorNewindex)
208.123.162.2 (talk) 07:50, 2 October 2010 (UTC)
thread_title: smallest K items

message: CONST n = 10000
  CLS
  DIM a(n)
  FOR i = 1 TO n: a(i) = RND: NEXT i
l = n
alfa:
 FOR i = 1 TO l / 2
  IF a(i) > a(i + l / 2) THEN
     t = a(i): a(i) = a(i + l / 2): a(i + l / 2) = t
  END IF
  NEXT
l = l / 2
 FOR i = 1 TO l / 2
  IF a(i) < a(i + l / 2) THEN
     t = a(i): a(i) = a(i + l / 2): a(i + l / 2) = t
  END IF
  NEXT
l = l / 2
IF l > 10 THEN GOTO alfa
FOR i = 1 TO l: PRINT a(i); : NEXT i
there seems to b algos with the 2 n 3 numbers 4 sorting, floodfill,muls, median of medians evn 4 factorizations, an heuristic one. good luck .Florin,Romania,38 old  — Preceding unsigned comment added by 93.118.212.93 (talk) 16:33, 8 July 2012 (UTC)
thread_title: possible new ideas abt median:a challenge 2 think, like reverse engineering-reengineering

message: The section titled Lower Bounds is a little disconnected. It mentions that Knuth discusses these, but then jumps to a paragraph about an upper bound in his book.  A trap for the unwary?  I can edit in the best known lower bounds, but should the section be retitled Upper and Lower Bounds for clarity?  Hardmath (talk) 14:17, 10 July 2014 (UTC)
thread_title:  Lower(?) bounds 

message: The section "Space complexity" says "The required space complexity of selection is easily seen to be k + O(1) (or n − k if k > n/2)". In what sense? There exists a simple algorithm with O(1) space complexity and O(n^2) time complexity: for each element of the input array, test whether it is the desired quantile by running through the array and counting how many elements are smaller than it and how many are equal. Jaan Vajakas (talk) 17:53, 25 May 2015 (UTC)
thread_title:  Space complexity 

message: This article should be expanded with a discussion on paralellization. OpenMP has reduction for min and max, not median. Also GPU's should help getting the median of a large dataset, but some algorithms are better suited for the task than others.  132.183.13.70 (talk) 17:08, 11 March 2016 (UTC)
thread_title:  Parallel Algorithms missing 

message: This page redirects from Hoare's algorithm and mentions Hoare once, but never specifically defines the algorithm.
--Quantum7 07:39, 1 April 2016 (UTC)
thread_title:  Hoare's algorithm 

message: The article currently says:
Rather than sorting the whole list or array, one can instead use partial sorting to select the k smallest or k largest elements. The kth smallest (resp., kth largest element) is then the largest (resp., smallest element) of the partially sorted list – this then takes O(1) to access in an array and O(k) to access in a list. This is more efficient than full sorting, but less efficient than simply selecting, and takes O(n + k log k) time, due to the sorting of the k elements.
What is this algorithm that does a partial sort in "O(n + k log k)" time? It's not presented in the article at all. This should either be clarified or removed.  — Preceding unsigned comment added by 46.208.172.118 (talk) 21:00, 24 April 2017 (UTC)
replies: text: I have a theory (though it's not well explained in the article). Did this text refer to using introselect followed by extraction of elements above the returned element, followed by as many of the returned element as needed to reach "k" elements and then a O(k log k) sort?  — Preceding unsigned comment added by 2A00:79E0:D:207:E459:A6FF:470E:2439 (talk) 16:15, 26 April 2017 (UTC)
thread_title:  What is this sorcery? O(n + k log k) partial sort?