时间复杂度为Shell排序?复杂度、时间、Shell

2023-09-11 04:40:33 作者:夏筝

首先,这里是我的Shell排序code(使用Java):

First, here's my Shell sort code (using Java):

public char[] shellSort(char[] chars) {
    int n = chars.length;
    int increment = n / 2;
    while(increment > 0) {
        int last = increment;
        while(last < n) {
            int current = last - increment;
            while(current >= 0) {
                if(chars[current] > chars[current + increment]) {
                    //swap
                    char tmp = chars[current];
                    chars[current] = chars[current + increment];
                    chars[current + increment] = tmp;
                    current -= increment;
                }
                else { break; }
            }
            last++;
        }
        increment /= 2;
    }
    return chars;
}

这是一个正确的实施壳牌排序(忘记,现在关于最有效的差距序列 - 例如,1,3,7,21 ......)?我问,因为我听说壳牌的最好情况下的时间复杂度排序为O(n)。 (见 http://en.wikipedia.org/wiki/Sorting_algorithm )。我看不到这样的效率水平正由我的code ++实现的。如果我说启发式,那么是的,但因为它的立场,没有。

Is this a correct implementation of Shell sort (forgetting for now about the most efficient gap sequence - e.g., 1,3,7,21...)? I ask because I've heard that the best-case time complexity for Shell Sort is O(n). (See http://en.wikipedia.org/wiki/Sorting_algorithm). I can't see this level of efficiency being realized by my code. If I added heuristics to it, then yeah, but as it stands, no.

话虽这么说,我现在主要的问题 - 我有困难,计算大O的时间复杂度为我Shell排序的实现。我确定了最外面的环为O(log n)的,中间环为O(n)和最内层的环也为O(N),但我知道内部的两个循环就不会真正为O( N) - 他们会比这少得多 - 他们应该怎样呢?因为很明显这个算法运行效率远远高于O((log n)的N ^ 2)。

That being said, my main question now - I'm having difficulty calculating the Big O time complexity for my Shell sort implementation. I identified that the outer-most loop as O(log n), the middle loop as O(n), and the inner-most loop also as O(n), but I realize the inner two loops would not actually be O(n) - they would be much less than this - what should they be? Because obviously this algorithm runs much more efficiently than O((log n) n^2).

任何指导是多少AP preciated因为我很失落! :P

Any guidance is much appreciated as I'm very lost! :P

推荐答案

在最坏的情况下,你的实现是Θ(N ^ 2),最好的情况是O(nlogn),这是合理的壳排序。

The worst-case of your implementation is Θ(n^2) and the best-case is O(nlogn) which is reasonable for shell-sort.

最好的情况εO(nlogn):

的最好情况是当阵列已经排序。在将意味着内if语句将永远不会是真实的,使内的while循环的恒定时间的操作。使用你已经用于其他循环的界限提供了O(nlogn)。通过使用增量恒定数量达到O(N)的最好情况。

The best-case is when the array is already sorted. The would mean that the inner if statement will never be true, making the inner while loop a constant time operation. Using the bounds you've used for the other loops gives O(nlogn). The best case of O(n) is reached by using a constant number of increments.

最坏的情况ε为O(n ^ 2):

鉴于你的上限为每一个你Ø循环((log n)的N ^ 2)为最坏的情况。但再添变数的间隙尺寸G。需要在内部,同时比较/交换的数量现在是与其中; = N / G。中间而比较/交换的数量为&lt; = N ^ 2 /克。添加上限比较/交往的每个间隙的数量在一起:N ^ 2 + N ^ 2/2 + N ^ 2/4 + ...&LT; = 2 ^ 2ε为O(n ^ 2)。这与你使用过的空白已知的最坏情况的复杂性。

Given your upper bound for each loop you get O((log n)n^2) for the worst-case. But add another variable for the gap size g. The number of compare/exchanges needed in the inner while is now <= n/g. The number of compare/exchanges of the middle while is <= n^2/g. Add the upper-bound of the number of compare/exchanges for each gap together: n^2 + n^2/2 + n^2/4 + ... <= 2n^2 ∊ O(n^2). This matches the known worst-case complexity for the gaps you've used.

最坏的情况εΩ(N ^ 2):

考虑其中所有的偶数定位元素都大于中值的阵列。奇数和偶数元件不进行比较,直到我们所需要的最后一次迭代比较/交换数达到1的最后一个增量为Ω(N ^ 2)。

Consider the array where all the even positioned elements are greater than the median. The odd and even elements are not compared until we reach the last increment of 1. The number of compare/exchanges needed for the last iteration is Ω(n^2).