合并K排序的数组/向量复杂度

Question

在研究合并k个排序连续数组/向量的问题以及它在实现方面与合并k个排序链表之间的差异时，我发现了两个相对简单的天真解决方案，用于合并k个连续数组和一个基于成对的优化方法 - 合并模拟mergeSort（）的工作方式。我实现的两个天真的解决方案似乎具有相同的复杂性，但是在一个大的随机测试中我运行它似乎比另一个更低效。

天真合并

我天真的合并方法如下工作。我们创建一个输出vector<int>并将其设置为我们给出的k向量中的第一个。然后我们合并第二个向量，然后合并第三个，依此类推。由于采用两个向量并返回一个向量的典型merge()方法在空间和时间上与两个向量中的元素数量渐近线性，因此总复杂度为O(n + 2n + 3n + ... + kn)，其中n为每个列表中的平均元素数。由于我们正在添加1n + 2n + 3n + ... + kn，因此我认为总复杂度为O(n*k^2)。请考虑以下代码：

vector<int> mergeInefficient(const vector<vector<int> >& multiList) {
  vector<int> finalList = multiList[0];
  for (int j = 1; j < multiList.size(); ++j) {
    finalList = mergeLists(multiList[j], finalList);
  }

  return finalList;
}

天真选择

我的第二个天真的解决方案如下：

/**
 * The logic behind this algorithm is fairly simple and inefficient.
 * Basically we want to start with the first values of each of the k
 * vectors, pick the smallest value and push it to our finalList vector.
 * We then need to be looking at the next value of the vector we took the
 * value from so we don't keep taking the same value. A vector of vector
 * iterators is used to hold our position in each vector. While all iterators
 * are not at the .end() of their corresponding vector, we maintain a minValue
 * variable initialized to INT_MAX, and a minValueIndex variable and iterate over
 * each of the k vector iterators and if the current iterator is not an end position
 * we check to see if it is smaller than our minValue. If it is, we update our minValue
 * and set our minValue index (this is so we later know which iterator to increment after
 * we iterate through all of them). We do a check after our iteration to see if minValue
 * still equals INT_MAX. If it has, all iterators are at the .end() position, and we have
 * exhausted every vector and can stop iterative over all k of them. Regarding the complexity
 * of this method, we are iterating over `k` vectors so long as at least one value has not been
 * accounted for. Since there are `nk` values where `n` is the average number of elements in each
 * list, the time complexity = O(nk^2) like our other naive method.
 */
vector<int> mergeInefficientV2(const vector<vector<int> >& multiList) {
  vector<int> finalList;
  vector<vector<int>::const_iterator> iterators(multiList.size());

  // Set all iterators to the beginning of their corresponding vectors in multiList
  for (int i = 0; i < multiList.size(); ++i) iterators[i] = multiList[i].begin();

  int k = 0, minValue, minValueIndex;

  while (1) {
    minValue = INT_MAX;
    for (int i = 0; i < iterators.size(); ++i){
      if (iterators[i] == multiList[i].end()) continue;

      if (*iterators[i] < minValue) {
        minValue = *iterators[i];
        minValueIndex = i;
      }
    }

    iterators[minValueIndex]++;

    if (minValue == INT_MAX) break;
    finalList.push_back(minValue);
  }

  return finalList;
}

随机模拟

长话短说，我构建了一个简单的随机模拟，构建了一个多维vector<vector<int>>。多维向量以2个向量开始，每个向量的大小为2，最后为600个向量，每个向量的大小为600。对每个向量进行排序，每次迭代时，较大容器和每个子向量的大小增加两个元素。我计算每个算法执行的时间长度如下：

clock_t clock_a_start = clock();
finalList = mergeInefficient(multiList);
clock_t clock_a_stop = clock();

clock_t clock_b_start = clock();
finalList = mergeInefficientV2(multiList);
clock_t clock_b_stop = clock();

然后我构建了以下情节：

我的计算结果表明两种天真的解决方案（合并和选择）都具有相同的时间复杂度，但上图显示它们非常不同。起初我通过说一个与另一个可能有更多的开销来合理化这个，但后来意识到开销应该是一个常数因素而不会产生如下的情节。对此有何解释？我认为我的复杂性分析是错误的？

Answer 1

即使两个算法具有相同的复杂度（在您的情况下为O(nk^2)），它们最终可能会有非常不同的运行时间，具体取决于您的输入大小和所涉及的“常数”因素。

例如，如果一个算法在n/1000时运行而另一个算法在1000n时间内运行，它们都具有相同的渐近复杂度，但它们的运行时间应该非常不同，以便“合理”选择n。

此外，由缓存，编译器优化等引起的效果可能会显着改变运行时间。

对于您的情况，尽管您的复杂度计算似乎是正确的，但在第一种情况下，实际运行时间应为(nk^2 + nk)/2，而在第二种情况下，运行时间应为nk^2 。请注意，按2划分可能很重要，因为k增加nk项可能会忽略不计。

对于第三种算法，您可以通过维护包含所有k向量的第一个元素的k元素堆来修改Naive选择。然后，您的选择过程将花费O(logk)时间，因此复杂性将降低到O(nklogk)。