Talk:Shellsort

message: O(N2) means something else in the context of calculation. Please write it plain. Thanks. --DLL 12:36, 26 January 2006 (UTC)
thread_title:  Nitrogen peroxyde ? 

message: For many years I tried to visualize the shells, much as there are moving bubbles in bubble sort.  Then I figured out that it was named after its inventor, and it was not an analogy.
Would it be worth capitalizing shell where it appears?
:Not all names remain capitalized in compound words, but it seems like a lot of people who write about it do capitalize it. Perhaps we should. Deco 00:21, 3 February 2006 (UTC)
thread_title:  Shell or shell ? 

message: First of all i think that instead of:
for (j = i - gap; j >= 0 && a[j] > value; --j) 
there should be
for (j = i - gap; j >= 0 && a[j] > value; j-=gap)
The code still yields the correct result because in the final step gap=1 and the alg does an insert sort.... But in terms of complexity it won't act well
Secondly i think the algorithm should also be explained in words, most of the time this helps a lot... A similar explanation like the one in the first link of the external links section would be great. I will insert it if you guys don't mind.
:I agree with your second point. However, your first point is incorrect; if we were to move j by gap, we would only sort one column of the matrix containing the list rearranged into gap columns, so the sort would not be effective. This is crucial. Deco 00:34, 19 June 2006 (UTC)
thread_title:  Algorithm question 

message: At the top of the article, it says "estimates range from O(n ^ 1.25) to O(n ^ 1.5)" - that is, it is believed to be impossible to go below n^1.25. Later it says - "Depending on the choice of gap sequence, Shellsort has a worst-case running time of ... O(n log^2 n)" - which, as far as I understand, means that a sequence is known for which it is n (ln n)^2. Does it mean something else? This is either a contradiction, or a very unclear wording which should be rewritten. Any ideas? -- Meni Rosenfeld (talk) 18:34, 18 June 2006 (UTC)
replies: text: The person who wrote the 1.25 was probably unfamiliar with the sequence permitting O(nlog2n) shellsort. I've updated it. Deco 00:24, 19 June 2006 (UTC)

text: I noticed the same contradiction and removed the "heap sort". If shells sort exceeds Θ(n log n) as is stated in the article, it can't be faster than heap sort for all input sizes. The comment I used is incomplete because I accidentally hit enter and somebody thought it a good idea to make the browser save the page in this case. Aragorn2 (talk) 10:43, 20 September 2010 (UTC)
thread_title:  Contradiction regarding running time? 

message: I've unlinked gap insertion sort in the article because this algorithm has virtually no use outside of shellsort, and is therefore most appropriate to discuss in this article (correct me if I'm wrong). We need to add discussion of gap insertion sort and of the specific sequences that produce certain asymptotic runtimes. I think it would be helpful to use the matrix characterization, where the list is rewritten as a table of k columns, where k is the gap, and the columns are sorted. Even the summary of this algorithm on the sorting algorithm page is already more complete than this article - maybe we should steal that. Deco 15:06, 19 June 2006 (UTC)
thread_title:  Need discussion of gap insertion sort and sequence details 

message: All instances of big O notation are written like O(x), however, in the second line Ω(n2) appears. Is this on purpose? If not, which version should be used?
Dummies102 02:38, 10 February 2007 (UTC)
replies: text: Ω(n2) simply means that the algorithm has an asymptotic lower bound of n2. Big O is roughly the asymptotic upper bound. Best123 00:55, 28 February 2007 (UTC)
thread_title:  big O/theta consistency 

message: Why on earth does the C/C++ implementation have a hard-coded starting increment of 3! That certainly isn't right! It should be "incrmnt = size/2", otherwise it's not much of a 'sequence; is it (3, 1)! —The preceding unsigned comment was added by 203.109.182.198 (talk) 05:28, 18 March 2007 (UTC)
replies: text: This may have fixed the problem, but it is not exactly an optimal solution. Quoted from higher up on the page: "Shellsort has a proven worst-case running time of O(n2) (using Shell's increments that start with 1/2 the array size and divide by 2 each time)." In other words, the C++ code uses the worst possible gap sequence. Aaron Rotenberg 03:39, 21 March 2007 (UTC)
thread_title:  incrmnt = 3 

message: Can you explain this line code in a better way?
(A comment deleted by its author. JDAWiseman (talk) 21:10, 3 April 2019 (UTC)
thread_title: for(incrmnt = 1 ; incrmnt<size;incrmnt=incrmnt*3+1);

message: The run time of O(nlog2n) in the list of worst cases isn't cited with a source. Flamesplash 00:17, 16 August 2007 (UTC)
thread_title: Missing Citation

message: I changed the line "The best known sequence is 1, 4, 10, 23, 57, 132, 301, 701, 1750." to "The best known sequence according to research by Marcin Ciura is 1, 4, 10, 23, 57, 132, 301, 701, 1750." because proof of it being optimal is not shown and empirical tests also show it is not optimal, other sequences perform better. Also added another intriguing sequence which performs well. Neverwinterx
Interesting... If empirical tests show that other sequences are better, can you quote one? According to the graphs, Ciura (2001) has the best sequence. 132.244.72.4 (talk) 16:41, 23 November 2012 (UTC)
thread_title:  Best known sequence

message: The article states that Shell sort is a generalization of insertion sort.  However, according to one source (the O'Reilly book "Mastering Algorithms with Perl"), it's a generalization of bubble sort (or an "advanced cousin" of it, to use that author's words).  Which is it?  My analysis of the pseudocode in the article seems to verify the latter, but I may be missing something.
--Paul (talk) 16:44, 8 June 2009 (UTC)
replies: text: The short answer is that it can probably be done either way, but it's a lot easier to conceptualise it as a generalization of insertion sort. NIST, in particular, says "On each pass i sets of n/i items are sorted, typically with insertion sort." This could probably be explained somewhat better, or at least more consistently, but there is a risk of introducing confusion if we're not careful. Dcoetzee 18:16, 8 June 2009 (UTC)
replies: text: The essence of Shell sort is sorting the k-chains (arrays with elements spaced k apart) for progressively smaller k down to and including k = 1.  Shell originally used insertion sort but bubble sort would also work.  Both insertion sort and bubble sort examine the same number of pairs and make the same number of swaps, just not in the same order, so the running time will be the same.  The n log2n Shell sort in my thesis is completely neutral on insertion sort vs. bubble sort because it sorts k-chains simply by scanning the array once for pairs of elements k apart and exchanging them if out of order, with no inner loop to keep moving moved elements along.  The reason people specified insertion sort in the 1970s is because that's what Shell specified.  Also Knuth in his book on sorting (AOCP 3) limits himself to insertion sort as the only exchange sort in the beginning, and then 25 pages later considers other exchange sorts including bubble sort, mentioning that "the classification ... is not always clear-cut" (but my edition is the 1973 one where he didn't seem to be drawing a clear distinction between insertion methods and exchange methods---in particular he doesn't list insertion sort per se among the exchange sorts which is odd).  --Vaughan Pratt (talk) 20:07, 28 March 2011 (UTC)
thread_title:  generalization of insertion sort or bubble sort? 

message: Why does this article say that this algorithm is worse than comparison sorts?  O(n log n) = O(n log2 n) because log2 of a number is just a constant multiplied by the log in any other base of a number.  Constants are factored out in big-O notation.  —Preceding unsigned comment added by 97.125.127.247 (talk) 19:05, 17 August 2010 (UTC)
thread_title:  O(n log n) = O(n log2 n) 

message: At User:MCiura/Shellsort, I have put a translation of the Polish article by myself, which is a GA on pl.wikipedia. After it is reviewed, I would like to move it to the main namespace. IMHO, the current explanations are too wordy but if you find something from the present version that you'd like to save, feel free to modify the new page. I will also be grateful for corrections of my English style and comments of any kind. One evident thing: folIowing all the references, I have used the name Shellsort, not Shell sort. Thanks, MCiura (talk) 17:46, 6 August 2011 (UTC)
replies: text: I've worked on the English of the proposed new article in response to your request on the Guild of Copy Editors Requests page, and I've left some comments on your talk page. In general, I feel that the present lead section is better and that the History section is desirable to keep. (I am not qualified to comment on the technical aspects of the two versions.) --Stfg (talk) 15:03, 5 September 2011 (UTC)
thread_title:  RFC: a new version of the article 

message: Anyone knows of a free gif animation to upload? --Solde9 (talk) 15:15, 11 August 2011 (UTC)
thread_title:  Animation 

message: Reference 21, "^ "kernel/groups.c". Retrieved 2011-03-30." is now invalid.
Since it appears to be a link to some linux kernel file or documentation for a specific file, it could be pointed to a more reliable source, like the own linux kernel page or some distribution page that holds the same file, like Debian (wich is heavily geared to developers). Or any other important distribution homepage.
The official kernel page can be used to access the linux source code tree. If someone can change the reference to point to:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=blob;f=kernel/groups.c
wich will show the source code. On the line 105 of this file begins the shellsort function.
Done, thanks for the link! MCiura (talk) 15:45, 6 February 2012 (UTC)
thread_title:  Invalid reference 

message: The two edits by GCRhoads give me pause. The performance claims seem to be based on a self-published blog, so I'm tempted to remove the edits due to WP:COI. Glrx (talk) 00:30, 18 June 2014 (UTC)
thread_title:  Rhoads additions 

message: I just dug up the Incerpi-Sedgewick paper and am confused that the bound stated here is N e sqrt(8 ln 2.5 ln N) instead of N e sqrt(8 ln 2 ln N). Also, the form stated in the article (N1+4/sqrt(2log2N)) appears to be better for comparison with the other bounds. Objections, anyone? --Björn  — Preceding unsigned comment added by 204.120.71.252 (talk) 05:48, 25 June 2014 (UTC)
thread_title:  Incerpi-Sedgewick Bound reproduced wrongly? 

message: Considering that inserting beyond 1 depth is not needed, and the amount of numbers in the gap sequence (all 3-smooth numbers), I think this gap sequence fits more in comb sort than in shell sort. 83.31.148.107 (talk) 08:43, 8 December 2017 (UTC)
thread_title:  Pratt's gap sequence 

message: The current animation, while accurate, does not visually display what operations it's taking. This could be confusing to readers who are unfamiliar with how the algorithm works. The animation on the article comb sort I think is a good example of showing what is being compared at each step of the algorithm. EstablishedCalculus 06:52, 24 May 2018 (UTC)
thread_title:  More Clear Animation? 

message: Has anyone ever analysed individual shellsort passes, rather than the statistics as a whole?
I am thinking of (1) net number of operations (number of comparisons, exchanges or moves) and (2) efficiency (number of moves or exchanges divided by number of comparisons)
I suspect that most passes would have similar statistics, but that the first pass or two (largest gaps) and possibly the last couple of passes (smallest gaps including 1) would differ from the main bulk of the passes. Has anyone ever looked at this to see what it tells us? It might show that the smallest gaps and the largest gaps have a greater effect on efficiency and might have to be chosen more carefully. 108.171.128.180 (talk) 13:45, 19 March 2019 (UTC)
thread_title:  Pass-by-Pass Analysis 

message: There is slight mention of coprime, but only slight. If there are sources commenting on its importance, they would be welcome. 
FYI, starting with 1, then choosing the number nearest to 2.2× that is coprime to all previous (except the 1), is the sequence 1, 2, 5, 11, 23, 51, 113, 247, 541, 1189, 2617, 5761, 12671, 27877, 61331, 134933, 296843, 653057, 1436731, 3160811, 6953783, 15298321, 33656309, 74043881, 162896543, 358372411, 788419321, 1734522497, …. (Quickie calc: please check before using.) The article suggests that this might be good, but is too OR for here. JDAWiseman (talk) 15:13, 30 March 2019 (UTC)
thread_title:  Coprime 

message: I have been chasing the actual time taken on 5-6 million items and have 2 observations.  I don't know if these are 'real improvements' or just 'on my compiler, on my computer, this runs faster'.   I don't have the resources nor the theory to run it down.  
first, the   for (i = gap; i < n; i += 1) statement is significantly (5 to 10% depending on the sequence used) faster if changed to   for (i = 1; i < n; i += 1).
second, the best sequence I have so far is 4.4 based, not 2.2 or 2.25 as suggested.  The 4.4 one beats everything on the main page in my code.  (that is 1, 4, 19,85,374,...).  I have found that stopping the sequence or choosing from it works better at 10% .. that is, for 6 million, stop at the first term > 600k.  The higher terms take longer than they contribute.
some numbers..
c++ standard sort, 0.65 sec for 6M
above modified, 0.95 sec for 6m
main wiki page code and sequences, 1.25 sec
4.4 was found by the computer, not selected.  I ran every sequence from 2.0 to 7.0 multiple times on multiple test runs and 4.4 came out on top repeatedly.  the worst sequences in those were the whole numbers (over 5 sec each for 2/3/4/5/6/7) which makes sense. 
Maybe someone can make some use of these ideas.
: Hello anonymous (please do end posts with four tildes). This is interesting. Two suggestions. Rather than the sequence {1, ⌊x⌋, ⌊x²⌋, ⌊x³⌋, ⌊x⁴⌋, ⌊x⁵⌋, …}, replace each term with the closest integer that is coprime to all previous gaps except 1. Also, don’t measure time, count comparisons. Please, given both of those, what’s the optimal x? JDAWiseman (talk) 13:17, 27 July 2019 (UTC)
thread_title:  Couple of ideas 

message: You give O(N) = N * N . for Shell's original sort. Surely that is not correct? A brain dead bubble sort will do that. I was under the impression, confirmed by doing some sorts by hand, that doing binary splits give N * log2 (N)  — Preceding unsigned comment added by 2001:8003:E422:3C01:40ED:3437:1883:5670 (talk) 09:58, 26 December 2021 (UTC)
thread_title:  O(N) for Shell's original sort 

message: It is displayed wrong in my Firefox and Opera. It looks like whatever reduces the size of SVGs, does not obey horizontal centering. The original file displays fine:  Gover7 (talk) 19:55, 21 December 2023 (UTC)
thread_title:  Graph of the number of operations again