为什么我的合并排序不像O(n*lgn））

Why is my merge sort not behaving like a O (n * lg n))?

本文关键字：lgn 我的 合并 排序 为什么      更新时间：2023-10-16

我基于Cormen‘s Book上的伪代码实现了这种合并排序。我正在复制它，因为它很短：

void merge(vector<double> &array, int start, int mid, int end) {
    int i = start;
    int j = mid + 1;
    int k = start;
    vector<double> b(array.size());
    while (i <= mid && j <= end) {
        if (array[i] <= array[j])
            b[k++] = array[i++];
        else
            b[k++] = array[j++];
    }
    while(i <= mid)
        b[k++] = array[i++];
    while(j <= end)
        b[k++] = array[j++];
    for (k = start; k <= end; k++)
        array[k] = b[k];
}

该部分应为O（n）

另一个应该是O（n*lg n），其中lg是2个基本上的日志

void mergeSort(vector<double> &array, int start, int end) {
    if (start < end) {
        int mid = (end - start) / 2 + start;
        mergeSort(array, start, mid);
        mergeSort(array, mid + 1, end);
        merge(array, start, mid, end);
    }
}

我用大小为1000（10^3）、10000（10^4）、50000（5*10^4），100000（10^5）、250000（2.5*10^5），500000（5*10^2）的随机向量实例做了一些实验。每个大小有30个实例。这是我对每个实例大小的平均结果：

1000 - ~0.000 s
10000 - 0.344 s
50000 - 20.456 s
100000 - 59.083 s
250000 - 360.814 s
500000 - 1729.245 s

运行合并排序时，我从linux时间命令中获取的所有经过时间（占用用户时间）。可见，它不是O（n*lgn）行为。我在这里缺少什么？我不知道它是否相关，但我的系统配置是：

OS: Fedora 18 - 64 bits
Processor: Intel® Core™ i3 CPU M 380 @ 2.53GHz × 4
Memory: 2.8 Gi

B

罪魁祸首是：

vector<double> b(array.size());

假设您从一个包含50万个条目的向量开始。对mergeSort的初始调用将对50万个条目的向量调用mergeSort，但只对前250000个元素进行排序。（然后它将在下半部分重复。）对mergeSort的下一个调用将接收完整的500000个元素数组，并调用mergeSort对数组的第一个和第二个125000个元素进行排序。等等。在这一过程中，mergeSort每次都会接收50万个条目的向量，但只对一个子集进行排序。最终，您将调用merge，在每次调用时都会分配和初始化一个由50万个元素组成的临时数组。

结果是n2*log（n）行为。这不是指数行为，但仍然不好。

我看到三种不同的解决方案：

  • 将该临时b分配一次，并将其作为参数传递给mergeSort和merge
  • 在merge中分配一个大小为end-start+1的临时数组。现在您必须使用偏移量来处理b[0]对应于array[start]的事实
  • 合并到位。你在这里不需要临时工。然而，这是不平凡的，并且将使算法成为O（N*（log（N））^2）算法

向量的重新定位似乎花费了很多时间。添加到矢量不是O（1）运算。尝试将向量更改为基本的C类型数组，您会注意到差异。此外，我从这些值中看到，它绝不是指数型的。也许是一个更高的多项式。

相关文章：