Talk:Comb sort

message: comb11 suggests that instead of a "constant scale factor of 1.25" some different method for selecting the gap would better serve.
It's perhaps also worth noting that the average ratio between prime numbers is almost the same as the "optimal gap ratio" for a sequence of maybe 17 prime numbers.  This average ratio increases for shorter sequences of prime numbers and decreases for longer sequences of prime numbers.  However, I imagine considerable testing would be needed to ascertain whether a "prime gap" approach would be a significant improvement.  —Preceding unsigned comment added by 72.83.127.158 (talk) 14:05, 27 January 2010 (UTC)
thread_title: comb11?

message: I think something must be wrong with the Python implementation if this truly is supposed to rival quicksort.  Even a simple bubble sort in Python beats it.
----
Combsort is an improved version of bubblesort that can be almost as good as more complex algorithms like quicksort.
Combsort's useage varies with the comb gapsize offset, so I suspect some of those empty fields might need "varies" as opposed to O notation responses.  The most optimized gapsize I've ever seen offered is at http://world.std.com/~jdveale/combsort.htm and uses a table.  Alternatively, the original version ( http://cs.clackamas.cc.or.us/molatore/cs260Spr01/combsort.htm ) uses /=1.3 instead.  I suspect that the other number, /='1.279604943109628' , is more precise.
How in depth should these encyclopedia articles be?  Another entry could be Hybrid Sort which uses Quicksort on lists larger than 6 elements and switches to Insertion Sort when the Quicksort divisions are small enough (20 or less elements), because on very small lists InsertionSort is actually faster.  Then there are the many specialized methods for special data.  Examples are Bentley Sedgewick, Sadakane's algorithm, and Forward Radix Sort for the sorting of all suffixes of a string as is required for the Burrows Wheeler Transform.
Also, the algorithms should be split into two groups: the comparison based ones that cannot be faster than n log n but do not need additional knowledge of the data, these being Quick Sort, Heap Sort, Merge Sort, Bubble Sort, etc., and the ones that do depend on the data being within a range of values or otherwise comparable to an external reference, these being Bucket Sort and Radix Sort.
----
Come to think of it, I think combsort might not be stable.
How is this different to shell sort?
According to NIST, shell sort completely sorts at each iteration whereas comb sort does only one pass per iteration.
----
Rabbits and turtles are fine, but does anyone know what the asymptotic complexity is? Arvindn 08:04, 9 Oct 2004 (UTC)
thread_title:  Rivals quicksort? 

message: I just wrote a version for C++
Hmm... I should template it, shouldn't I? I'll work on that.
Update: Done!
 template <typename RandomAccessIterator>
 void combSort11(RandomAccessIterator first, RandomAccessIterator last)
 {
    bool flag = true;
    int leng = last - first;
    int offset = leng;
    RandomAccessIterator array = first;
    const double shrink = 1.247330950103979;
    while (offset!=1 && !flag)    // finished only if offset is 1 and no swaps were made
    {
        flag = true;
        if (offset>1)
            offset /= shrink;
        if (offset==9 || offset==10)    // makes it Combsort11
            offset = 11;
        for (int i=0; i<(leng-offset); i++)
            if (array[i]>array[i+offset])
            {
                std::swap(array[i], array[i+offset]);
                flag = false;
            }
    }
 }
DevastatorIIC 01:14, 8 March 2006 (UTC)
replies: text: I guess flag should be initialized to false instead. --Como (talk) 14:33, 9 April 2008 (UTC)

text: The C++ implementation doesn't work. The Java implementation currently on the article page doesn't work for the array (1 20 30 40 50 6 70 80 90). I'm removing the Java implementation from the article for the moment; frankly, I don't think we need a Java implementation if the Python implementation is correct (which I'm not sure of, but it seems plausible). One imperative language is enough. --Quuxplusone 21:24, 11 May 2006 (UTC)
thread_title:  C++ Implimentation 

message: Both http://world.std.com/~jdveale/combsort.htm and http://cs.clackamas.cc.or.us/molatore/cs260Spr01/combsort.htm are gone from the web for reasons unknown. I noticed that many other webpages outside of Wikipedia also reference these nonexistent webpages. A brief search failed to relocate these articles. Jafet 07:51, 23 July 2006 (UTC)
thread_title:  Broken links 

message: This sentence in the intro doesn't make sense to me:
:"improves on bubble sort and rivals in speed more complex algorithms like Quicksort"
The fragment "more complex algorithems ..." seems misplaced. Is there a missing work or something? perhaps "more than"??? Fresheneesz 19:39, 20 September 2006 (UTC)
thread_title:  What does this sentence mean...? 

message: This algorithm is not an O(n log n) worst case or average case algorithm, as noted above - but is listed as such at sorting algorithm. Did the original article include a complexity analysis? If not, it shouldn't list any complexity there - it's OR to do our own nontrivial algorithm analysis. If Dobosiewicz's algorithm is the same, I'm sure he included an analysis that we can use.
Also, er, the note claiming it has "small code size" in sorting algorithm is silly - shellsort has very similar code and better complexity and is accompanied by no such note. 
Also, the phrasing "almost as good as [...] quicksort" is implausible - for both small and large lists I seriously doubt it could be competitive in any practical implementation, because I believe it does a lot more comparisons overall. Dcoetzee 03:43, 7 December 2007 (UTC)
thread_title: False complexity at [[Sorting algorithm]]

message: () ...the average-case time for both
variants is Omega(n^2/c^p) where p is the number of increments and c=2
for Dobosiewicz sort and c=4 for Shaker sort.... I don't have access to the full paper though. The key result is reproduced in a survey by Paul Vitanyi. Interestingly he mentions that a final insertion sort is required, suggesting that your 'killer sequences' are known to always exist, but doesn't cite a source for that. Bazzargh (talk) 18:09, 9 October 2008 (UTC)
replies: text: Note the text "for certain sequences of increments" in the abstract of "Analyzing variants of Shellsort". I don't have the full text, either, but I bet that they do not mean prime increments. Knuth already pointed out in 1973 that Shellsort would be slower if the intervals had common factors. Indeed, Shellsort _is_ O(N*N) worst case if all intervals are even. Try to sort the sequence {0,1,0,1,0,1,0,1.....}  — Preceding unsigned comment added by Comocomocomocomo (talk • contribs) 14:50, 14 February 2013 (UTC)
thread_title:  Citation for complexity 

message: template<class t> inline void combsort(t*a, int n)
  {
    int g=n,s;
    t*j,*i=a-1,z;
    while(++i<a+n-g?z=*i,z>*(j=i+g)?*i=*j,*j=z:--s:(s=n,i=a-1,g=(g/=1.3)>8&g<11?11:g?:1),s>1);
  }
Yeah, that's simple alright.  —Preceding unsigned comment added by 62.92.25.130 (talk) 05:33, 5 August 2009 (UTC)
thread_title:  "Simplified C++ Implementation" 

message: I think the animation of the sorting algorithm is wrong. It looks like a simple Bubble sort is done over the data but not using the whole range at first and increasing it later on. A correct animation can seen here: http://www.cs.ubc.ca/~harrison/Java/sorting-demo.html. --Walderich (talk) 07:58, 23 February 2012 (UTC)
thread_title:  Wrong Animation 

message: I have implemented various sort algorithms in Perl: bubble sort (standard), bubble sort (optimized,i.e. not trying to sort the part of the array already sorted), comb sort (standard), comb sort (optimized with the same improvement when the gap becomes 1)), merge sort, quick sort and shell sort. Then I have timed these various sorts in a number of situations (with number of elements to be sorted between 1,000 and 10,000,000, each time running each sort a large number of times to even out possible artifacts). 
It will be no surprise to anyone, I think, that bubble sort (even optimized) has just very poor performances, especially when the list to be sorted grows. I won't go any further into this, and limit the rest of this discussion to optimized comb sort, merge sort, quick sort and shell sort. (In fact, I have also implemented a couple of other algorithms, such as selection and insertion sort, but my point here focuses on the four mentioned faster algorithms).
For arrays populated with random or pseudo-random values, quick sort and shell sort are consistently 2.25 to 2.30 faster than comb sort, which is itself 1.35 to 1.39 faster than merge sort. Part of these differences may be linked to the relative efficiency of my own implementation of these different approaches, but an interesting fact is that the gaps are very consistent, whether running on an array of 2,000 or 1,000,000 elements, which indicates that all four algorithms scale up almost identically.
For arrays that are very far from random, the situation is very different. I have tried to use arrays that are already sorted, that are sorted in reverse direction, or that are close to be sorted in direct or reverse direction. In those cases, quick sort and shell sort exhibit extremely poor performance, whereas merge sort and comb sort continue to behave very well. For example, for arrays with 5,000 elements almost sorted, quick sort and shell sort are both more than 10 times slower than merge sort and comb sort. For arrays sorted in reverse direction (or almost sorted in reverse direction), merge sort and comb sort are about 20 times faster (still with 5,000 elements). With larger arrays almost sorted in either direction, the difference in favor of merge sort and comb sort is even more blatant.
Statistically, the cases where shell sort and quick sort break, compared to the total number of possible cases, are very rare, probably extremely rare in fact. But in real life, the situation is quite different. It is quite common, for example in the index of a database or in the rankings of sport teams, to have data almost sorted and needing to be sorted again. In those cases, quick sort and shell sort, although the fastest algorithms of those tested here for random data, behave very badly.
This has led software vendors and other sorting algorithm implementers to use merge sort (which has a worst case scenario in O(n log n) rather than usually faster algorithms such as quick sort whose worst case scenarios are much poorer. As an example, the Perl implementers have decided, as of Perl 5.08, to shift the standard sort function from quick sort to merge sort. On average, merge sort is 2 to 3 times slower than quick sort, but merge sort does not suffer from worst case scenarios such as almost sorted data as quick sort.
Now, in every single test I have made (and I ran tens of thousands of automatized tests in all kinds of conditions), comb sort has proven at least 35% faster than merge sort. I have seen some (very) small fluctuations in performance results, but I haven't seen any single case where comb sort behaves as bad as quick sort, or anywhere near that, for almost sorted data. There may be cases where comb sort also breaks, but I have yet to see one single case. So, although my tests are far from exhaustive, I submit the idea that comb sort might be a better candidate that merge sort for a general sorting algorithm that does not break on specific situations. I realize that far more work is needed before one can confidently choose comb sort instead of merge sort as the best basic algorithm, but at least, there is rather convincing evidence that it might be the case. 
As a final note: even if comb sort really has a mean complexity in O(n²), if the coefficient is really 10e-80, then it is really negligible. I know what the theory usually says about it: even if the coefficient is very low, an algorithm in n log n will always always end up to be better than an algorithm in n² provided the data is large enough. But if the n² coefficient is so small, the data is not going to be large enough for years or probably decades ahead. In my humble opinion, it does not really make sense, as of today, to take into account data volumes that are just not imaginable as of today or in the foreseeable future. Therefore, although it is probably or possibly theoretically correct to state a complexity of O(n²) for comb sort, it would make more sense in my humble view to state a real world complexity neglecting this n² factor and giving real world approximation (I have no idea of whether this should be n log n or something less).
Laurent rosenfeld (talk) 00:51, 25 November 2012 (UTC)
replies: text: Comb sort is O(n log n) on average, just as quick sort, merge sort and heap sort. Shell sort is worse than O(n log n) on average, so I will not discuss it. The advantage of merge sort is that it performs a stable sort, which might be important in some applications. The main drawback of merge sort is that it requires O(n) additional memory. The other three algorithms (comb, quick, and heap) require only O(1) additional space, but they are not stable sort algorithms. Quick sort is the fastest, but it is O(n²) worst case. We must suppose that comb sort is O(n²) worst case too, until somebody proves it otherwise (see the discussion above). Security applications and real time applications are specially sensible to worst case scenarios. That is why libraries should not offer them as all-purpose sorting algorithms. As far as I know, the most extended sorts in libraries are merge sort (for being a stable sort with O(n log n) average and O(n log n) worst case time), and introsort (a mixture of quicksort and heapsort that requires only O(1) additional memory, and is O(n log n) average and O(n log n) worst case time). Como (talk) 07:39, 7 December 2012 (UTC)
thread_title:  Comb sort versus Merge Sort, Quick Sort and Shell Sort 

message: Comb sort and cocktail sort are strategies for handling "turtles" in bubble sort. Comb sort moves turtles more than one space, while cocktail sort turns turtles into rabbits temporarily. Have any papers analyzed the combination of the two? --Damian Yerrick (talk) 03:06, 3 December 2014 (UTC)
thread_title:  Cocktail comb sort 

message: The pseudocode is looping until gap is 1 and swapped is False. But if we have multiple copies of the same number in our list, when we get down to a gap of 1, swapped will never become False because of these lines:
    if input[i] = input[i+gap]
        swapped := true
So you will be stuck in an infinite loop. Please let me know if I am misunderstanding this pseudocode.
-----------------------------------------------------
I think there is an implicit understanding that the integer division that takes place when `gap` is recalculated will result in 0.
    
    gap := int(gap / shrink)
This implies that when `gap == 1` is true, then 1/1.3 will result in 0. See Division (mathematics), Case #5 for more specific information regarding this.
TraugdorOriginal (talk) 14:28, 8 August 2016 (UTC)
thread_title:  Confused by the pseudocode 

message: I made an edit to the pseudocode recently regarding a case when the ends of an array are sorted, but the middle is not. This case will cause the Comb Sort to fail on the first pass. A javascript implementation of my edit is as follows:
    'comb': function(a) {
        var n = a.length, gap = n, shrink = 1.3, swapped, ignorePass1 = true;
        do {
            gap = Math.floor(gap/shrink);
            if(gap < 1)
                gap = 1;
            var i = 0
            swapped = false;
            do{
                if(a[i] > a[i+gap]) {
                    common.swap(a, i, i+gap);
                    swapped = true;
                    ignorePass1 = false;
                }
                i++;
            }while(i+gap < n);
        }while(gap > 1 && (swapped == true || ignorePass1));
    }
In JavaScript and other languages, Integer Division will give a whole number less than the actual result if floating point division had been used.
This should suffice to let the edit stand and be approved by the general community.
A sample array that will fail to be sorted because of this flaw is found here: https://gitlab.com/snippets/23840. The array is 10 characters long. 10/1.3 equals 7. With a gap of 7, the first pass would give no swaps. Since the algorithm thinks the array is already sorted, it will exit on the first pass without actually doing anything.
TraugdorOriginal (talk) 14:36, 8 August 2016 (UTC)
replies: text: After checking the pseudocode with a colleague, we found that the sort will fail with a segmentation fault if the list to be sorted is only one element in length.
TraugdorOriginal (talk) 20:03, 8 August 2016 (UTC)
thread_title:  Pseudocode needs a rework 

message: Article says:
:Comb sort is a relatively simple sorting algorithm originally designed by Włodzimierz Dobosiewicz in 1980.[1][2] Later it was rediscovered by Stephen Lacey and Richard Box in 1991.[3] 
The comb sort algorithm or something close to it appears 6 years before 1980, in Kernighan and Plauger's 1974 book The Elements of Programming Style.  K&P called it "Shell sort", apparently erroneously.  In particular, K&P's version uses exchanges like comb sort, rather than insertions ("sifting") like in the Shellsort article.  I'm not sure how to fix the text here. 173.228.123.121 (talk) 04:34, 25 February 2018 (UTC)
thread_title:  History