Talk:Sorting algorithm

message: template <class iterator> void gnome(iterator first, iterator last){ // O(n^2)
	iterator pos = first;
	while (pos <= last) {
		if ((pos == first) || ((*pos) >= *(pos - 1)))
			++pos;
		else {
			std::iter_swap(pos, pos+1);
			--pos;
		}
	}
}
Is this a genuine question about the quality of your code? If so, I'd probably suggest posting on StackExchange or something.  — Preceding unsigned comment added by 2605:6000:1522:400B:10FB:405:731E:8F1B (talk) 15:59, 4 October 2017 (UTC)
thread_title:  How bad is this code 

message: I'm surprised at not finding slowsort here. While it is one of the less serious kind of algorithms, it is interesting since it is, however slowly, steadily progressing to its goal (as opposed to, say, bogosort).
The algorithm:
# Find the maximum
## Find the maximum of the first half
## Find the maximum of the second half
## Find the largest of those maxima
# Sort the remainder
It is described at http://c2.com/cgi/wiki?SlowSort and was, according to that page, first published in the satyrical article "Pessimal algorithms and the simplexity of computations" by A. Broder and J. Stolfi, in ACM SIGACT News vol. 16 no. 7, pages 49--53, fall 1984. I haven't located that article yet, though. Both links given there are broken.  —Preceding unsigned comment added by SQB (talk • contribs) 20:08, 26 July 2009 (UTC)
thread_title:  Slowsort 

message: Stupid sort -  This article was copied from the deleted Wikipedia article which sat in the "Stupid sort" page. -- A perfect demonstration how stupidity proliferates in the internet with the help and andorsement of wikipedia :-) 23:25, 6 February 2010 (UTC)
replies: text: Yes, the algorithm does seem to be a joke.  I recall seeing it here before and wondered what had happened to it.  But it seems the term is also used to refer variously to bogosort or to gnome sort.  Currently, stupid sort redirects to bogosort.... — Smjg (talk) 02:26, 16 December 2011 (UTC)
thread_title:  Stupid sort 

message: For example, the time complexity for bubble sort is listed as n2.
While its computational complexity (time + space) is on the order of n2 (2n2-2n), the worst case time complexity is not n2.
worst case time complexity (comparisons) for bubble sort is (n2/2) - (n/2).  But they are all wrong.  —Preceding unsigned comment added by 74.140.173.132 (talk) 05:57, 24 February 2010 (UTC)
replies: text: I don't understand what you say, because Ordo((n2/2) - (n/2)) = Ordo(n2). Any term less than n2 is overshadowed by n2, and the constant 1/2 is irrelevant. The complexity is a scalability function when the function compares to itself dealing with increasingly huge arrays. Rursus dixit. (mbork3!) 19:48, 6 July 2010 (UTC)
thread_title:  Why are worst case time complexities wrong? 

message: Should it be O(n log n) instead n log n in comparison table?  —Preceding unsigned comment added by Conan (talk • contribs) 00:06, 9 May 2010 (UTC)
thread_title:  Missing O()? 

message: Comparison table states that its "memory" is log(n). But, as far as I know, quick sort is in-place sort. Even its own article said so: "...Coupled with the fact that quicksort is an in-place sort and uses no temporary memory...".  —Preceding unsigned comment added by 85.222.169.174 (talk) 13:44, 4 June 2010 (UTC)
replies: text: As it says later in the quicksort article, memory is required for the stack frames which are implicit in the recursion. "No temporary memory" is just wrong. 67.162.90.113 (talk) 19:59, 2 November 2010 (UTC)
thread_title:  Quick sort error 

message: In the worst case, quicksort sorts a group of items in O(N2), where N is the number of items. If randomization is incorporated into the algorithm, however, the chances of the worst case actually occurring become diminishingly small, and on average, quicksort has a runtime of O(N*Log(N)). Other algorithms guarantee a runtime of O(N*Log(N)), even in the worst case, but they are slower in the average case. Even though both algorithms have a runtime proportional to N*Log(N), quicksort has a smaller constant factor - that is it requires C*N*Log(N) operations, while other algorithms require more like 2*C*N*Log(N) operations  —Preceding unsigned comment added by Tarun telang (talk • contribs) 10:31, 11 June 2010 (UTC)
thread_title:  Randomized Quiz Sort Algorithm 

message: I find it rather ironic that this table does itself not appear to be sorted! The "exchanging" methods are kept together and are ordered alphabetically, but other than that the order seems to be pretty random. I am in favour of sorting this table according to Method and then name, but other options such as by average case complexity and then name also seem fine to me.
It may be like a bit of a plug that Timsort has been placed at the top of this table. There seems to be less reason for it to appear in the table compared to some algorithms that are currently omitted.
Secondly, I'd also like to see a best case column added to the table. Then it would make sense to add other algorithms such as Binary Insertion Sort whose best case differs from normal Insertion Sort, but the average and worst cases are the same. It would also make sense to hilight the fact that bubble sort (amoung others) can be implemeneted with an O(n) best case.
Several other algorithms such as Bitonic Merge Sort, Bingo Sort, Odd-Even Transposition Sort, Strand Sort, Squeeze Sort, and Order Sort to name a few, could also be added.
Malcolm  —Preceding unsigned comment added by 118.92.109.220 (talk) 03:01, 13 June 2010 (UTC)
replies: text: 13 years later. I just sorted the table in a somewhat heuristic order of best to worst for general use. General use in this case means that you are generally concerned with speed or memory used when you have a large number of elements to sort. For small number of elements, unless you do it repetitively and a lot, nobody is really concerned with speed. So they are now ordered, first by best average, then best worst case, then best best case, then memory used, then stability. If your concern is code size or memory used, you can still reorder the list as you wish. Hope this helps. Now ordering the list in this way reveals that there may be some issues. If you compare Comb sort with Library sort for instance, they have identical best and worst limits, but very different averages. Is this really correct? Dhrm77 (talk) 19:05, 22 October 2023 (UTC)
thread_title:  "Comparison of algorithms" table ordering 

message: The linked file "File:SortingAlgoComp.png" has a very poor quality of information.
There are some spelling mistakes "Tourament" (missing 'n') and "Interger" (extra 'r')
The description states: "This chart shows the complexity of different algorithms when sorting one million integers (from 1 to 1000).". However it is not clear where these numbers come from. Are they comparison counts? Are they swap (or assignment) counts? A combination of both of these measures?
What was the initial ordering of the data? Over how many runs were these numbers averaged?
How is it that so many of the algorithms all have exactly 1.99316x10^7 as the count?
What does "Sorting networks" mean in this picture, and how is the result for it able to not be a whole number?
How was bogosort measured given the ridiculously high number shown?
I believe that in its current form, this image adds no value to the article and should be removed.
If the information is to be explained and kept then it should converted to a textual form instead.
Malcolm
118.92.109.220 (talk) 04:45, 13 June 2010 (UTC)
replies: text: I've just removed it. It is incoherent, and it is OR. But mostly it is incoherent. Apparently nobody cares for the quality of this article, that this was allowed to linger here for a year and a half at least, and God knows for how long really. Appalling. WillNess (talk) 17:39, 25 December 2011 (UTC)
thread_title:  Issues with attached file: SortingAlgoComp.png 

message: This sentence makes no sense to me:  "Efficient sorting is important to optimizing the use of other algorithms (such as search and merge algorithms) that require sorted lists to work correctly."  I can't fix it because I don't know what it's trying to say.  So I'm inviting others to work on this.  If no fix is forthcoming, I will likely delete this sentence. 
By the way, it might be helpful in the summary of each algorithm to describe its performance on various types of datasets (e.g., random, nearly sorted, reversed, few unique elements).  MichaelBluejay (talk) 12:56, 22 June 2010 (UTC)
thread_title:  Fixing a lede sentence 

message: Consider this sorting network as included in the Sorting network article. Let's put [2, 1a, 1b, 0] on the wires with 'a' and 'b' as markers for the initial order without them belonging to the sorting key. If this sorting network is stable, we can expect it to return [0, 1a, 1b, 2]. The way I see it, it just doesn't:
2, 1a, 1b, 0 is the initial configuration.
1b, 1a, 2, 0 results from the first comparison. 2 > 1, thus we swap.
1b, 0, 2, 1a results from the second comparison. 1 > 0, thus we swap.
0, 1b, 1a, 2 results from the next two comparisons. We swap both since 1 > 0 and 2 > 1.
0, 1b, 1a, 2 is the result. No swap in the last comparison since 1 = 1.
However, [0, 1b, 1a, 2] does not equal [0, 1a, 1b, 2], which was our expected result. From this counterexample follows that sorting networks are not stable sorts in the general case.
So… am I missing anything here?  —Preceding unsigned comment added by 129.13.72.197 (talk) 11:23, 23 June 2010 (UTC)
thread_title:  Are sorting networks truly stable sorts? 

message: Quantum sorting is not faster than normal sorting (http://arxiv.org/abs/quant-ph/0102078) but might offer better time-space tradeoffs. Thus, Quantum sort does not need to have its own article. I propose merging the brief content from quantum sort into the sorting algorithm article. Comments? Please also comment on the quantum sort talk page so that we can delete that article and incorporate it into this one. --DFRussia (talk) 20:56, 29 June 2010 (UTC)
thread_title:  Quantum sort 

message: The section Bubble sort claims:
:This algorithm is highly inefficient, and is rarely used[citation needed], except as a simplistic example.
Looks like false to me. Because of the code brevity of the algorithm, it instead should be heavily used on pretty short lists in naive Q&D implementations where a sort is needed. Also it is often combined with quicksort and quickersort for when the to-be-sorted sublists are under a certain length, such as 3 or 4 elements. This use to improve the sorting speed. So the statement is dubious. Rursus dixit. (mbork3!) 19:57, 6 July 2010 (UTC)
thread_title: Bubble sort

message: I think bubble sort is stable (in contrary to what that written in the table)  —Preceding unsigned comment added by 79.177.127.22 (talk) 09:55, 2 November 2010 (UTC)
replies: text: I just reverted some changes that claimed BS stability depends on the implementation. BS should be stable because neighboring elements are not swapped if they are already in order (and two equal elements are in order). Consequently, equal elements will not get out of order. (They can get out of order when non-neighboors are swapped as in Shell short.) Sadly, my statements are WP:NOR, and I don't have a WP:RS citation for BS stability. Glrx (talk) 21:55, 7 November 2010 (UTC)
thread_title:  Bubble sort stability 

message: When it says n*log(n) what is the base of the log function? Is it binary (2), decimal (10), natural (e), or some other base?  —Preceding unsigned comment added by 69.91.165.139 (talk) 20:04, 15 November 2010 (UTC)
replies: text: In big O order notation, the base of the logarithm doesn't matter -- log2, log10, and ln are all related by just a constant. In particular algorithms, there will be a logical base to use: a binary sort would be base 2 and a radix 10 sort would be 10.  But again, in terms of big O, the actual base doesn't matter; constant multipliers are discarded. Glrx (talk) 20:49, 15 November 2010 (UTC)
thread_title:  Log Base 

message: I came looking for assistance in manually sorting tens of thousands of random Election Ballots into a hundred geographic (Precinct) districts. Similarly the Postal Services machine-sort millions of pieces of mail into millions of buckets (zipcodes, routes and addresses). Carrier personnel manually direct-sort their mail into an array of "pigeon-holes" before delivery distribution.
Unfortunately all emphasis here is towards electronic Data-processing. I've got to give these lots of thought to determine applicability to physical-sorts, using physical motions, requiring real-time, and limited buckets within reach or operator constraints. Does EDP sort-theory apply, or have lessons for large physical sorts?
Are info or comments about best physical-sort algorithms appropriate here? What differences apply due to human or mechanical vs electronic/cyber media and speeds? HalFonts (talk) 07:20, 19 November 2010 (UTC)
replies: text: It is usual to measure comparison sorting algorithms based on the number of comparisons, and assume that the number of element moves (or copies) is proportional. As a physical sort problem, consider sorting a deck of playing cards, commonly by insertion sort. Unlike for EDP, a whole group of already sorted cards moves up or down as one operation. I did once, just to see that I could do it, sort a deck of cards with quicksort. Some EDP sort algorithms easily adapt as physical sort algorithms, and others don't.  Reminds me, that radix sort was commonly used to sort decks of computer cards in the early EDP days. There were machines built to do this combination of electronic and physical sorting. Gah4 (talk) 13:44, 4 September 2019 (UTC)
thread_title:  Manual (Physical) Sorting Algorithms 

message: The best case for TimSort should be O(n). It is not just a hybrid mergesort but a hybrid natural mergesort.
If the data contains runs that are ordered or reverse ordered or a mixture, then it is between O(n) and O(n * log n).
See http://bugs.python.org/file4451/timsort.txt
The same can be said for SmoothSort. If the runs are ordered (but not reverse ordered), then it is O(n).
The best cases on these should reflect this.
Stephen Howe (talk) 22:39, 25 November 2010 (UTC)
thread_title:  TimSort 

message: What's happened to this section? Just two curly brackets at the moment. Sam Dutton (talk) 14:01, 26 November 2010 (UTC)
thread_title:  Shell sort 

message: I dont think this is true, it is only true for quicksort for linked lists. It is not how the pivot is handled, as the article describes, but the fact that all equal elements within the partition set must retain their original order while partitioning. To do so, requires a stable partition (function in C++ library). stable partition requires auxilary memory and cant be done in O(N) without the memory. Any comments?
Stephen Howe (talk) 21:46, 10 December 2010 (UTC)
replies: text: See Quicksort#Complex version. Glrx (talk) 05:28, 11 December 2010 (UTC)
thread_title:  Quicksort can be stable? 

message: The overview says library sort was first published in 2004, but the library sort page says 2006.  Which is correct?  John lindgren (talk) 13:49, 10 June 2011 (UTC)
thread_title:  Library sort -- 2004 or 2006? 

message: I found the general algorithm for spaghetti sort, as well as linking articles.  — Preceding unsigned comment added by Ahshabazz (talk • contribs) 00:11, 27 June 2011 (UTC)
thread_title:  Spaghetti (Poll sort) 

message: I find this sorting algorithm to be amusing:
http://rosettacode.org/wiki/Sorting_algorithms/Sleep_sort  — Preceding unsigned comment added by 174.137.113.43 (talk) 00:50, 20 July 2011 (UTC)
thread_title:  Sleep sort 

message: that... you could add in the table if an algorithm is online or not.
http://en.wikipedia.org/wiki/Category:Online_sorts
Mdtr (talk) 03:26, 3 August 2011 (UTC)
thread_title:  add information about online sorting algorithms 

message: I would appreciate a clarification, either on this page or the logarithms page, of what is meant by \log^2(N).  KlappCK (talk) 15:00, 30 August 2011 (UTC)
replies: text: The equation has been clarified to be n*(logn)^2, which matches what is stated on STL's webpage and in STL books (Duvavic1 (talk) 01:08, 14 September 2011 (UTC)
thread_title: Clarification of Notation

message: According to the definition given at the start of the article, duplicates-removing sorting is not sorting. But that kind of algorithms exist; some languages/run-time systems have built-in sort functions with the possibility to specify whether it is needed to remove the duplicates at the same time while sorting, or to preserve them. 
One example: pigeonhole sort with removal of duplicates is essentially what the array-based sieve of Eratosthenes is doing while collecting ⁄ marking the composites, and list-based variant exists which performs duplicates-removing mergesort.
Where and how can this be addressed? Or is it already, somewhere? Any pointers, anyone? Thanks. WillNess (talk) 08:20, 22 September 2011 (UTC)
thread_title:  Duplicates-Removing Sorts 

message: A I just published a new sorting algorithm I worked on for the last 18+ months. I think Over-sort is past "worthy of notice", and into ground breaking territory, but I'm probably biased.  — Preceding unsigned comment added by 84.229.4.103 (talk) 08:24, 14 October 2011 (UTC)
thread_title:  A New Sorting Algorithm: Over-sort 

message: Standard Template Library includes a stable_sort() function, but does not define how it is implemented. In the case of Microsoft's Visual Studio, stable_sort() uses a temp vector (1/2 the size of the data to be sorted), and is not an in-place merge sort. It uses insertion sort to create chunks of 32 elements, then merges chunks until chunk size equals vector size. The sort algorithms section should not include a reference to Standard Template Library as an example of an in place merge sort. A specific implementation of STL's stable_sort() might use an in-place merge sort, but stable_sort() is not defined that way. Rcgldr (talk) 02:06, 9 December 2011 (UTC)
replies: text: VS2005 stable_sort allocates a temporary buffer 0.5 times the size of the data to be sorted, so does VS2010 and VS2015. I suspect all versions of VS stable_sort allocate a half size temporary buffer. stable_partition does allocate a full size temporary buffer. Rcgldr (talk) 08:23, 15 December 2015 (UTC)
thread_title:  standard template library stable_sort() is not always in place merge sort 

message: Before you start the sorting of the N given elements you should check if the given elements already have the desired sort order (check if (a[i-1] <= a[i]) for all i=(1, .. N-1)).
This additional check operation has only a linear run time complexity O(N). That means if the given array is already sorted (this is always the best case) so the run time complexity is always O(N).
This additional check operation can be executed at the begin of each sort algorithm. That means in particular that each sort algorithm in the best case always has a linear run time complexity O(N).
Aragorn321 (talk) 05:54, 19 July 2012 (UTC)
thread_title:  Implementation code improvements for all sort algorithms 

message: Currently, this column has only red (n^2 or worse) and green (better than n^2). Should nlog(n) be made yellow, for consistency's sake? 140.247.41.147 (talk) 13:48, 23 July 2012 (UTC)
thread_title:  Yellow boxes in the "best case" column. 

message: August 31, 2012
To whom it may concern (at Wikipedia),
Back in the late 1970's I read about two sorting algorithms that are not mentioned at all in this "Sorting algorithm" article.  They are Quickersort and Quickestsort.  At that time: Quickersort was the latest published improvement of Quicksort; and Quickestsort was the fastest sorting method possible theoretically and (its algorithm was) a trade secret of the U.S.A. Federal Government.  If anyone knows more (history) about this, please add it to this "Sorting algorithm" article.  Quicksort and Quickersort were written about in the book: "Sorting and Sort Systems" by Harold Lorin, , Copyright © 1975 by Addison-Wesley Publishing Company, Inc., part of "The Systems Programming Series" [book #4 of 4].  I don't remember where I read about Quickestsort.  I thought it was in that book, but it is not listed in the index. 
Sincerely yours,
JPD 22:15, 31 August 2012 (UTC)
thread_title:  Quickersort AND Quickestsort 

message: Euclid sort sorts in O(N*log(N)) time n needs O(1) mem
first we got two groups of sorted items to b merged
lets try to describe backward possible variant:
first we c what is the last item (in reverse order) from the second group that remains at its place
second we c where is moving up the first contestant , in reverse order, by following in reverse order, the elements of first group
third we c how many elements from the second group will come compactly with the contestant that i mentioned
fourth we apply some Euclid arange function to put the elements in the rite place
when exit the loop we probabily will have at least an Euclid arange (as much, but no more) to get the array sorting done
idd wish credits if the case
Florin Matei, Romania
93.118.212.93 (talk) 07:36, 22 February 2013 (UTC)
replies: text: Please read WP:OR; if this were published, it could be added (provided we can figure out what it means).  — Arthur Rubin  (talk) 16:55, 25 February 2013 (UTC)
thread_title:  ok, let me try describe Euclid sort 

message: its all abt merging two sorted groups: main repeated action is to move same number of elements from group first n group second (group interchange same no of elements) so we'll have all the elements of groups (sorted in the future) but not in place, then well repeat starting with the group of less length 4 not charging that much the stack... as a strategy we can alternate between remained smaller group n the bigger 1:1 alternate that assure O(log(n)) stack with some strategy against hazard.
when memorize parameters of a group in the stack , memorize also the "breaking point" also
  93.118.212.93 (talk) 08:28, 4 March 2013 (UTC)
thread_title:  an evn more simple sorting algo that challenges O(N*log(n)) time n o(1) mem 

message: This sort only works on a sequential set of numbers in some random permutation, using swaps to sort the set of numbers. The worst case number of swaps is n-1. Example code for when the set of number is {0, 1, ..., n-1} stored in an array a[]:
void sort(void)
{
int i;
    for(i = 0; i < n; i++)
        while(   a[i] != a[a[i]])
            swap(a[i],   a[a[i]]);
}
Several
Rcgldr (talk) 09:18, 27 April 2013 (UTC)
replies: text: Infinite loop? (Made a mental off-by-one error here...) —Ruud 10:38, 28 April 2013 (UTC)
replies: text:  Given the constraint that the array of size n contains a permuted set of numbers {0, 1, ... , n-1}, the worst case number of swaps is n-1. I've since figured out that this algorithm can be expanded to sort an array based on a set of sorted indexes:
//      A is an array of size n
    A[] = ... ;
//      generate array of indexes I
    for(i = 0; i < n; i++)
        I[i] = i;
//      sort I based on values in A
    sort(I, A);
//      sort A using the sorted list of indexes in I
//      while also sorting I
    for(i = 0; i < n; i++){
        while(     I[i] !=  I[I[i]] ){
            swap(A[I[i]], A[I[I[i]]]);
            swap(  I[i],    I[I[i]] );
        }
    }
Rcgldr (talk) 01:04, 29 April 2013 (UTC)
replies: text:  Cycle sort would seem like an appropriate name, but it has already been taken, although it does seems to be based on the same underlying principle: "It is based on the idea that the permutation to be sorted can be factored into cycles, which can individually be rotated to give a sorted result." I wouldn't be surprised if this sort doesn't have a name, as it seems to be mostly of theoretical interest: with the given preconditions it shouldn't be too hard to keep the list sorted in memory in the first place. The extension of the sort to work on key-value pairs can be applied to any sorting algorithm. —Ruud 17:10, 29 April 2013 (UTC)

text:  It's a special case of cycle sort: special_cycle_sort in B. K. Haddon, "Cycle-Sort: A Linear Sorting Method", The Computer Journal, 1990. —Ruud 17:16, 29 April 2013 (UTC)
replies: text: Since it swaps instead of rotating, maybe it should be called swap sort? I forgot to mention that each swap places at least one element in it's "correct" location. Rcgldr (talk) 07:55, 30 April 2013 (UTC)
replies: text:  Most in-place sorting algorithms, including bubble sort and quicksort, work by swapping elements. This specific algorithm, though, goes through each cycle in the permutation one-at-a-time. Thus the number of iterations of the for-loop in which you perform at least one iteration of the nested while-loop is always exactly equal to the number of cycles in the permutation. —Ruud 11:54, 30 April 2013 (UTC)

text: So the main enhancement of this algorithm is the part that sorts the array A[] while performing the special cycle sort on I[]. I searched again but wasn't able to to fing any references citing that special cycle sort could be used for this purpose. Rcgldr (talk) 04:01, 1 May 2013 (UTC)
thread_title:  Is there a name for this sort algorithm? 

message: There should be a section explaining what an in place sort is just like there is a section for explaining stability of sorting  — Preceding unsigned comment added by Nileshrathi01 (talk • contribs) 14:07, 5 October 2013 (UTC)
thread_title:  Adding explanation for in-place sort 

message: "Sorting networks" aren't a singular algorithm that can be described as a single best/worst/average case for time and memory, but they're listed as such in the chart. They're also listed in a special category for sorts that are incredibly impractical or require special hardware. That may be true for the AKS sorting network it's apparently referring to, but small and efficient sorting networks are actually a lot faster than insertion sort, even though insertion sort is credited as being the fastest. In my experience they're anywhere from 2 to 5 times faster than insertion sort.
What should be done about this? My recommendation is to remove sorting networks from the chart entirely and only refer to them as a concept that can be applied to many sorting algorithms (AKS, even-odd, bitonic, bubble and insertion, etc.), either to construct hardware or to make an algorithm for fixed-size data sets.  — Preceding unsigned comment added by BonzaiThePenguin (talk • contribs) 03:40, 11 April 2014 (UTC)
replies: text: It doesn't seem like there is a reference supporting its position in the table, so if you have a good source that describes sorting networks as a strategy that can be applied to many different sorting algorithms, I think you could easily make that change. – FenixFeather (talk)(Contribs) 04:34, 11 April 2014 (UTC)
thread_title:  Sorting networks section still needs work 

message: I'd like to see an explanation of the terms used in the Method column of the Comparison Sorts table in the Comparison of Algorithms section: Partitioning, Merging, Selection, Insertion, Exchanging, Distribution, Random Shuffling. These don't seem to be explained until later in the article, if at all. I think a short paragraph or illustration describing these methods is warranted.2620:36:8000:10:95B8:2D6C:17C9:12AB (talk) 16:59, 17 September 2014 (UTC)
thread_title:  Explanation of Comparison Sort methods 

message: If "Quicksort for linked lists" has different characteristics than "Quicksort for arrays" -- one is stable, and the other is not -- then they are different enough for this article to list them as two separate algorithms.
Stephen Howe suggested they were different in #Quicksort can be stable?.
Is there a more reliable source that mentions "Quicksort for linked lists" than
"Stable Quicksort With Linked List"
or
"Optimal Quicksort for Single Linked List"
?
— Preceding unsigned comment added by DavidCary (talk • contribs) 22:36, 21 August 2015
: They are the same algorithm. You can view the linked list as supplying an extra O(n) space for making a stable partition; the array version doesn't have that extra space, so it cannot do a stable partition. Glrx (talk) 21:00, 26 August 2015 (UTC)
thread_title:  Quicksort variants 

message: hello and thank you for reading about this "not paper book published" interesting sort algo.
http://sourceforge.net/projects/headsort/
This isn't on the main page or book but i beleive DOES matter.  Simply because it was never tried in publications doesn't mean it doesn't matter; results matter, and are in forma gnu sort(1) for trial.
Mergesort is stable and fast, it heuristicly "bins" like radix and speedily compares LINES of data using strcmp - making MULTI-DIMENSIONAL sorting (multi field) very fast.  extra fields (dimensions) are (smartly) catenated onto previous ones (gnu sort does this) and never compared if strcmp stops before then.
However - Mergesort heuristic failure is comparing item that have ALREADY been compared.
Traditionally it is thought a "triangulation sort" cannot be fast because it needs two or thee dimensions to compare characters (also no cpu strcmp to use).  However it gains by never comparing two things twice.  That still lags behind merge sort best case, but does win in some cases.
"hsort" or headsort can win in a few major ways.
ONE: when the first bin is done (which is triangulated and cannot finish sooner), headsort program can begin piping sorted output. (unlike a simple "sift up" sort, it can finish the tail quickly as well).  this is important if anyone is waiting to view data or has a battery that cannot withstand needless background heat while they view.
TWO: "hsort" found two NEW improvements which may well make it a good algo to use in general.  First instead of data[line][field][characters] it tried data[field][line][characters] and nearly being deleted attempt: found a special case which allowed a dimension reduction of 1, at moderate cost (a good improvement).  Doing so ate up all time to try the other...
THREE: Next and recently, HSORT tried a simpler dimensional reduction.  Using a 1d array sorted that output ptr to 3d array.  Impossible per say: but distribution counting allows it on the tail, so it is fully 1/2 true.
FOUR: the old adage *foo[][][] is expesive is not as true as it had been in the 8086 days.  New CPU can do some extra dimensions in 1 CPU tick, which remove more of the remaining handicap of the 'hsort' algorithm in practice.
With those two (or fee) dimensional reductions my tests show that hsort beats "merge sort" used in gnu sort heavily in best cases, and also still wins in headsort's worst cases: just all around faster FOR multi dimensional sorting.
I'd like others comments but I'm well aware its' rare any proffessors exchange comments on algorithms.
hsort is debuggable (unlike recursive heuristics, it's flow is mostly natural)
hsort also has implications in distributive computing because it can recurse dimensions and doesn't require merging or waiting per say (implementation of piping finished bins in 123 order aside which is easy, which is always true single process)
Allowing an sssumption this hsort is faster in a worthy manner, it does matter in that scientific algorithms can finish or never finish.  Many math algorithms have sorting at their core (for example, factoring).  While for "web server technology" sorting might not be important - it is important whether scientific processes can finish and show a result.  And that is simply re-iterating a textbook big-O-notation explanation.
LASTLY. hsort algorithm is not an idea it's available for use (has other algo in a collection too) as a gnu-sort compatible program, and has a demo "mini sort" prog to make it's portability and use more clear.
— Preceding unsigned comment added by 72.219.207.23 (talk) 23:16, 19 March 2016 (UTC)
thread_title:  NEW - release of hsort (triangulation sort) and why it matters 

message: The image that shows whether a sort is stable or not (Sorting_stability_playing_cards) correctly shows the output of an unstable sort. The example of a stable sort can really only be said to not be shown to be unstable. If the description indicated that it would consistently (or provably) work in that way, it would be better.
Dcrafti (talk) 03:59, 17 January 2017 (UTC)
thread_title:  The example image of stable sorting is not quite correct 

message: The section "Comparison of algorithms" gives n2 as the average time complexity of comb sort. I am not competent enough to suggest what the correct complexity is (I suspect that this is a rather sophisticated problem with a result of something like nsome number between 1 and 2), but n2 cannot be right; in practice this algorithm sorts huge lists at speeds comparable to nlogn algorithms. Same about worst case actually.  — Preceding unsigned comment added by 2001:7D0:8891:1380:BC17:C2C1:9181:5154 (talk) 07:53, 7 August 2017 (UTC)
thread_title:  Comb sort in the comparison table 

message: Shell sort is clearly not a variant of bubble sort. Why is it listed under the headline "bubble sort and variants"?
Dp99 (talk) 09:34, 6 June 2018 (UTC)
replies: text: It you wanted to know how to make bubblesort into an NlogN sort, shellsort would do it. Gah4 (talk) 20:38, 4 September 2019 (UTC)
thread_title:  Shell sort is in the wrong section 

message: The "Twin Sort Technique" (https://arxiv.org/abs/1710.07992) is the latest core computer sorting algorithm and got published recently, and I am the main author of it.  Can this be covered and added to your portal (https://en.wikipedia.org/wiki/Sorting_algorithm)?  Millions of students, researchers and engineers get benefited out of this addition.
VeereshDevireddy (talk) 15:10, 16 August 2018 (UTC)
replies: text: The answer is "definitely not" until it is widely cited in professional literature. After looking at your paper, I predict that time will never come. McKay (talk) 07:30, 17 August 2018 (UTC)
thread_title:  Twin Sort Algorithm 

message: It occurs to me that caching effects on modern (or not so modern) processors can greatly affect the speed of some memory access patterns, and that could be significant in some sort algorithm comparisons.  Not knowing where else to mention it, though it might be useful in pages for specific sort algorithms, I am starting here. Gah4 (talk) 20:43, 4 September 2019 (UTC)
replies: text: I agree with "caching effects on modern (or not so modern) processors can greatly affect the speed of some memory access patterns". "(...) and that could be significant in some sort algorithm comparisons", yes. For instance, a sorting algorithm which works on the whole input from the start (such as bubblesort) is less cache-aware than an algorithm such as mergesort which can focus on local solutions, which tend to be contiguous in memory, before going over a larger slice of whole input. BernardoSulzbach (talk) 22:28, 4 September 2019 (UTC)
replies: text: One example of this is on a processor with an 8 way cache, a 4 way merge sort (without heap, just an if/else tree to determine smallest element), there are 4 cache lines for the 4 runs being merged, and a 5th cache line for the merged output. The end result in my testing is that 4-way merge sort is about 15% faster than 2-way merge sort. Rcgldr (talk) 02:53, 6 September 2019 (UTC)
thread_title:  cache 

message: The dynamic web page in the second paragraph implies (at least to me) a Publicly accessible web page, whose content runs afoul of FERPA.
The second paragraph of the Stability section starts with:
 Stability is important for the following reason: say, if the data is sorted first by student name, in some cases, dynamically on the webpage, and now the data is again sorted by which class section they are in.
A webpage containing student name and  corresponding class section data would at first glance appear to be "'directory information" but is actually an education record.  Therefore if the web page is accessible by others than those with a defined, institutional, education purpose, the web page would be in violation of FERPA.
My feeling is those learning these topics should not be creating things, that, if used with real-life data, would be in violation of the law.
 
 
: None of this is relevant to the article. The article is about algorithms for sorting data, not about what should be done with the data.  The text also says nothing about publishing the data, so the question of what is legal to publish is entirely irrelevant. McKay (talk) 22:25, 27 February 2020 (UTC)
thread_title:  Example stable sort vs. FERPA 

message: I would like to discuss a revert done by an anonymous IP. The reason for the revert was that the expected runtime is given in the average case. This is, however, wrong. The expected runtime is different from the average case. These two names are different concepts: the average case is a description of the input. The input meaning here the list to sort. We assume some distribution of the input and calculate the expectation for the runtime over this distrubtion. This is different for "expected runtime". The 'expected' in 'expected runtime' does not relate to the input, but instead to what we often call 'random bits'. The 'random bits' are not part of the input (this would make the whole concept of probablistic programming ad absurdum). Therefore we can not say that the average-case is identical to the expected runtime. We have infinitely many expected runtimes, especially we have a worst-case expected runtime, a best-case expected runtime and again we also have an average-case expected runtime.
Even worse, saying that the worst-case runtime of bogosort is infinite is at best misleading. That is because there is really no concept in which infinite would be a meaningful runtime for bogosort. I would accept using the phrase 'certainly unbounded', meaning assuming that there is no randomess, the runtime is not bounded by any function depening on the input. Even saying that the runtime is unbounded (without using the word certainly) is misleading as the probability for unbounded runtime is 0 and even the expected runtime is at most n x !n. I would therefore ask to redo my change to fit more with the given source (which uses the same semantics) and with the current research. --PhoenixIra (talk) 17:25, 22 June 2020 (UTC)
replies: text: Worst case is commonly meant to be the worst possible case, which is unbounded for bogosort. The input in this case would commonly include the worst possible random seed as well. At any rate, we follow the sources, and your addition (and the matching addition at Bogosort) was unsourced. Cite a reputable source and interprets that the worst case behavior as you are and perhaps we can use it. - MrOllie (talk) 17:51, 22 June 2020 (UTC)
replies: text: I don't agree. Citing CLRS: "The worst-case running time of an algorithm gives us an upper bound on the running time for any input. Knowing it provides a guarantee that the algorithm will never take any longer. We need not make some educated guess about the running time and hope that it never gets much worse." (Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein. Introduction to Algorithms, Third Edition. MIT Press 2009, page 28) and later claryfing: "When analyzing the running time of a randomized algorithm, we take the expectation of the running time over the distribution of values returned by the random number generator. We distinguish these algorithms from those in which the input is random by referring to the running time of a randomized algorithm as an expected running time. In general, we discuss the average-case running time when the probability distribution is over the inputs to the algorithm, and we discuss the expected running time when the algorithm itself makes random choices." (Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein. Introduction to Algorithms, Third Edition. MIT Press 2009, page 117). CLRS also sometimes uses the phrase 'worst-case' complexity when refering to randomized algorithms, when they really mean 'certain worst-case'. Including random bits in the input would also make the runtimes totally absurd: for an infinite runtime, you would need infinite random bits, making an infinite input. This is obviously broken. Again, expectation and worst/average-case are different concepts. Coming to bogosort, we have 'Sorting the slow way: an analysis of perversely awful randomized sorting algorithms': "Let S denote the number of swaps carried out by bogo-sort on a given input x of length n. Then E[S]=(n − 1)n! in the worst and average case." and "Let C denote the number of comparisons carried out by bogo-sort on a given input x of length n. Then E(C) = (e − 1)n! + n − O(1) in the worst-case" (Gruber, H.; Holzer, M.; Ruepp, O., "Sorting the slow way: an analysis of perversely awful randomized sorting algorithms", 4th International Conference on Fun with Algorithms, Castiglioncello, Italy, 2007 (PDF), Lecture Notes in Computer Science, 4475, Springer-Verlag, pp. 183–197, Corollary 6 and 10) and .Again, I am on board with using the phrase "unbounded certainl runtime" and "n x !n expected runtime", however, infinite is wrong and don't mentioning the worst-case expected runtime is bad. --PhoenixIra (talk) 18:11, 22 June 2020 (UTC)
replies: text: The Gruber et al. conference paper looks good, you've convinced me. Just add a citation to that. - MrOllie (talk) 18:24, 22 June 2020 (UTC)
thread_title:  Average Case vs Expected Runtime for Bogosort 

message: An introductory sentence says, "For optimum efficiency, the input data should be stored in a data structure which allows random access rather than one that allows only sequential access."
But that is true only when the cost of random access is very small. If the volume of input data is too long to fit in available fast memory (e.g., RAM), then having input data stored in a data structure residing on slow memory (e.g., hard disk, or magnetic tape) then such a data structure can be terrible.
I'm changing the introductory sentence to say, "For optimum efficiency, input data in fast memory should be stored in a data structure which allows random access rather than one that allows only sequential access." DavidForthoffer (talk) 20:41, 4 February 2021 (UTC)
thread_title:  "For optimum efficiency, the input data should be stored ... " 

message: First bullet in 'Classification'
Computational complexity (worst, average and best behavior) in terms of the size of the list (n). For typical serial sorting algorithms, good behavior is O(n log n), with parallel sort in O(log2 n), and bad behavior is O(n2)
Does anyone know what the 'O' for bad behaviour for parallel sorting is?
Darcourse (talk) 10:12, 22 July 2021 (UTC)
thread_title:  Bad behavior for parallel sort 

message: Link: https://en.wikipedia.org/wiki/Timsort — Preceding unsigned comment added by 2001:16b8:1e5b:ba00:2c00:cbff:fe64:7ae (talk • contribs) 
:No, it is there. Look again. - MrOllie (talk) 19:26, 18 August 2021 (UTC)
thread_title:  Comparison list is incomplete Tim Sort is missing 

message: I was surprised to find no page on wikipedia for comparing online sorting algorithms, and no section in the Online algorithm page. I'm not sure if it deserves its own page, a section in this page with a new comparison table, or maybe a column in an existing comparison table? Privychick (talk) 13:32, 18 March 2022 (UTC)
thread_title:  Online sorting 

message: What is the point of the tk screenshot at the top?? —Tamfang (talk) 00:46, 21 April 2023 (UTC)
replies: text: Seeing no response ... —Tamfang (talk) 04:52, 3 November 2023 (UTC)
replies: text:  I agree that it wasn't very good.  But I think something should be there.  Do you see any good ones at Category:Sort algorithms?  Perhaps :File:Visualization of Gnome sort.gif Bubba73 You talkin' to me? 05:29, 3 November 2023 (UTC)
replies: text: Perhaps an animation of a less stupid sort. ;)  Heapsort or Quicksort for example. —Tamfang (talk) 06:23, 3 November 2023 (UTC)

text:  There are some better ones at the Wikimedia Commons: Category:Animations of sort algorithms, see this  Bubba73 You talkin' to me? 06:31, 3 November 2023 (UTC)
thread_title:  tk pic 

message: Just wondered if AI sorts should be added:
* https://www.youtube.com/watch?v=n2qCry_o2Fs
* https://www.youtube.com/watch?v=nF81NVBFLcE
GrahamHardy (talk) 16:42, 23 June 2023 (UTC)
replies: text: By which I guess you mean improved algorithms recently discovered by AIs.  If they are novel concepts they ought to be listed, but the videos seem to say they are speedier versions of known approaches.  (I'll try to read the articles linked under the first video.) —Tamfang (talk) 23:45, 18 July 2023 (UTC)
replies: text: The DeepMind AI sorting algorithm targets sorting 3 to 5 elements and in the case of 5 elements, saves one compare. Not much of a breakthrough. Rcgldr (talk) 07:38, 24 July 2023 (UTC)
replies: text:  That could potentially be significant if it is in a recursive divide-and-conquer algorithm.  Bubba73 You talkin' to me? 05:36, 3 November 2023 (UTC)
thread_title:  AI Sorting 

message: 1 strength of ArrayV is, that the numbers, which are visualized as bars, are always integers, as I have never seen pigeonhole sort failing to sort an array.
There are some wrong time complexities in Sorting algorithm#Others.
Simple pancake sort should be O(n) best and O(n2) average and worst and Bitonic sorter should be O(n log2n), best average and worst, where log2n means (log n)2. Well, these time complexities fit well to the results in https://www.youtube.com/watch?v=8MsTNqK3o_w&t=2825s andhttps://www.youtube.com/watch?v=v4Uo0Pi6odo&t=15s. The fastest a sorting algorithm can reach is O(n). In array v oof 2, sb broke ArrayV by running parallel bitonic sort with 16384 numbers, but I think, it was just a freeze bug, like https://www.youtube.com/watch?v=vlLrmCifVRY&t=1646s.
Another strength of ArrayV is how the sorting algorithms are visualized. AceOfSpadesProduc100 himself said in (follow-up video) Threaded pattern-defeating merge sort on ArrayV-v4.0, in Parallel bitonic sort on ArrayV, in Parallel odd-even merge sort on ArrayV and in ArrayV-v4.0's parallel sorting algorithms, that he uses an Intel Core i7-9750H, which has 6 cores and 12 threads. But, the way ArrayV visualizes the sorting algorithms lets the parallel sorting algorithms do the fully parallel method. For example, parallel bitonic sort could use flan sort rotations. 94.31.83.138 (talk) 19:43, 23 August 2023 (UTC)
thread_title:  mistakes and ArrayV 

message: bold = correction
part 2: https://www.youtube.com/watch?v=wqibJMG42Ik
patience sort: O(n) best, O(n log n) average and worst, O(n) memory, stable
tournament sort: O(n log n) best, average and worst, O(n) memory, stable
bitonic sort: O(n log^2 n) best, average and worst, O(1) memory, unstable
odd-even merge sort: O(n log^2 n) best, average and worst, O(1) memory, unstable
pairwise sorting network: O(n log^2 n) best, average and worst, O(1) memory, unstable
stooge sort: O(n^2.71) best average and worst, O(1) memory, unstable
slow sort: O(n^(log n)) best average and worst, O(1) memory, unstable
variants and hybrids: https://www.youtube.com/watch?v=FntVy6lPVyo
cartesian tree sort: O(n log n) best, average and worst, O(n) memory, stable
Stalin sort: O(n) best, average and worst, O(1) memory, stable
sleep sort: O(n) best, O(n + r) average and worst, O(n) memory, stable
miracle sort: O(n) best (on a sorted list), O(inf) average and worst, O(1) memory, stable
power sort: O(n * n!) best, average and worst, O(n * n!) memory, stable
A sorting algorithm can not be faster than O(n).
Stalin sort increases unsorted values to the largest previously read value (https://www.youtube.com/watch?v=hyOlWQ9MLPI). For example, [1, 2, 5, 3, 6, 4, 10] becomes [1, 2, 5, 5, 6, 6, 10].
Sleep sort is a time-based sorting algorithm. The smallest number wakes up first and the largest number wakes up last (https://www.youtube.com/watch?v=ktgxMtWMflU&t=210s). Equal numbers will wake up at the same time, but waking up is swapless.
Miracle sort only makes comparisons and power sort prints all the permutations in auxiliary arrays, so both of them are swapless.
Swaps of non-adjacent numbers are what makes a sorting algorithm unstable (https://www.youtube.com/watch?v=KJuxI1BBLyQ&t=403s).
some examples
cycle sort, bitonic sort, odd-even merge sort, pairwise sorting network, stooge sort and slow sort: Swap non-adjacent numbers. = unstable
insertion sort and binary insertion sort: Swap only adjacent numbers. = stable
patience sort, tournament sort, cartesian tree sort, Stalin sort, sleep sort, miracle sort and power sort: no swaps = stable 94.31.89.138 (talk) 20:28, 28 October 2023 (UTC)
thread_title:  corrections for "Explaining EVERY Sorting Algorithm" parts