スライディングウィンドウの中央値を計算するための非自明なアルゴリズム

実行中の中央値を計算する必要があります：

• 入力： $n$、$k$、vector $(x_1, x_2, \dotsc, x_n)$。

• 出力： vector $(y_1, y_2, \dotsc, y_{n-k+1})$、ここで$y_i$はの中央値です$(x_i, x_{i+1}, \dotsc, x_{i+k-1})$。

（近似による不正行為はありません。正確な解を求めます。要素$x_i$は大きな整数です。）

サイズ探索木を維持する簡単なアルゴリズムがあり$k$ます。合計実行時間は$O(n \log k)$です。（ここで「検索ツリー」とは、対数時間での挿入、削除、および中央値クエリをサポートする効率的なデータ構造を指します。）

しかし、これは私には少し愚かなようです。中央値だけでなく、サイズkのすべてのウィンドウ内のすべての順序統計を効果的に学習します。さらに、特にkが大きい場合、これは実際にはあまり魅力的ではありません（大きな検索ツリーが遅くなる傾向があり、メモリ消費のオーバーヘッドが自明ではなく、キャッシュ効率が悪いことが多いなど）。$k$$k$

大幅に改善できることはありますか？

下限はありますか（たとえば、単純なアルゴリズムは比較モデルに漸近的に最適ですか）。

編集：デビッドエップスタインは、比較モデルのための素敵な下限を与えました！それにもかかわらず、些細なアルゴリズムよりも少し賢いことをすることは可能だろうか？

たとえば、これらの線に沿って何かを行うことができます。入力ベクトルをサイズ部分に分割します。各部分をソートします（各要素の元の位置を追跡します）。そして、区分的にソートされたベクトルを使用して、補助データ構造なしで実行中の中央値を効率的に見つけますか？もちろん、これはまだO （n log $k$ですが、実際には、配列のソートは検索ツリーを維持するよりもはるかに高速になる傾向があります。$O(n \log k)$

編集2： Saeedは、検索ツリー操作よりもソートの方が速いと思う理由をいくつか見たいと思っていました。以下は、、n = 10 8の非常に簡単なベンチマークです。$k = 10^7$$n = 10^8$

• ≈8s：それぞれk個の要素を持つベクトルをソート$n/k$$k$
• ≈10s：要素を持つベクトルの並べ替え$n$
• ≈80s：サイズkのハッシュテーブルでの挿入と削除$n$$k$
• ≈390s：サイズkのバランスの取れた検索ツリーでの挿入と削除$n$$k$

ハッシュテーブルは比較のためだけにあります。このアプリケーションでは直接使用しません。

要約すると、ソートとバランスの取れた検索ツリー操作のパフォーマンスにはほぼ50倍の差があります。そして、を増やすと事態はさらに悪化します。$k$

（技術的詳細：データ=ランダムな32ビット整数。コンピューター=典型的な最新のラップトップ。テストコードはC ++で記述され、標準ライブラリルーチン（std :: sort）とデータ構造（std :: multiset、std ::を使用） unsorted_multiset）。2つの異なるC ++コンパイラ（GCCおよびClang）、および標準ライブラリの2つの異なる実装（libstdc ++およびlibc ++）を使用しました。伝統的に、std :: multisetは高度に最適化された赤黒木として実装されています。）

Here's a lower bound from sorting. Given an input set $S$ of length $n$ to be sorted, create an input to your running median problem consisting of $n-1$ copies of a number smaller than the minimum of $S$, then $S$ itself, then $n-1$ copies of a number larger than the maximum of $S$, and set $k=2n-1$. The running medians of this input are the same as the sorted order of $S$.

そのため、計算の比較モデルでは、時間が必要です。おそらく、入力が整数であり、整数ソートアルゴリズムを使用している場合は、さらに改善できます。$\Omega(n\log n)$

編集：このアルゴリズムは現在ここに表示されます：http：//arxiv.org/abs/1406.1717

はい、この問題を解決するには、次の操作を実行するだけで十分です。

• それぞれがk個の要素を持つベクトルを並べ替えます。$n/k$$k$
• 線形時間の後処理を行います。

大まかに言うと、アイデアは次のとおりです。

• 入力の2つの隣接するブロックとbを考えます。両方ともk個の要素があります。要素があること聞かせて1、2、。。。、KとB 1、B 2、。。。、入力ベクトルxの出現順にb $a$$b$$k$$a_1, a_2, ..., a_k$$b_1, b_2, ..., b_k$$x$ます。
• これらのブロックを並べ替えて、ブロック内の各要素のランクを学習します。
• Augment the vectors $a$ and $b$ with predecessor/successor pointers so that by following the pointer chains we can traverse the elements in an increasing order. This way we have constructed doubly linked lists $a'$ and $b'$.
• One by one, delete all elements from the linked list $b'$, in the reverse order of appearance $b_k, b_{k-1}, ..., b_1$. Whenever we delete an element, remember what was its successor & predecessor at the time of deletion.
• Now maintain "median pointers" $p$ and $q$ that point to lists $a'$ and $b'$, respectively. Initialise $p$ to the midpoint of $a'$, and initialise $q$ to the tail of the empty list $b'$.

• For each $i$:

  • Delete $a_i$ from list $a'$ (this is $O(1)$ time, just delete from the linked list). Compare $a_i$ with the element pointed by $p$ to see if we deleted before or after $p$.
  • Put $b_i$ back to list $b'$ in its original position (this is $O(1)$ time, we memorised the predecessor and successor of $b_i$). Compare $b_i$ with the element pointed by $q$ to see if we added the element before or after $q$.
  • Update pointers $p$ and $q$ so that the median of the joined list $a' \cup b'$ is either at $p$ or at $q$. (This is $O(1)$ time, just follow the linked lists one or two steps to fix everything. We will keep track of how many items are before/after $p$ and $q$ in each list, and we will maintain the invariant that both $p$ and $q$ point to elements that are as close to the median as possible.)

The linked lists are just $k$-element arrays of indexes, so they are lightweight (except that the locality of memory access is poor).

Here is a sample implementation and benchmarks:

• https://github.com/suomela/median-filter

Here is a plot of running times (for $n \approx 2\cdot 10^6$):

• Blue = sorting + post-processing, $O(n \log k)$.
• Green = maintain two heaps, $O(n \log k)$, implementation from https://github.com/craffel/median-filter
• Red = maintain two search trees, $O(n \log k)$.
• Black = maintain a sorted vector, $O(n k)$.
• X axis = window size ($\approx k/2$).
• Y axis = running time in seconds.
• Data = 32-bit integers and random 64-bit integers, from various distributions.

Given David's bound it's unlikely you can do better worst case, but there are better output sensitive algorithms. Specifically, if $m$ in the number of medians in the result, we can solve the problem in time $O(n \log m + m \log n)$.

$O(\log m)$ time. If the new counts indicate that the median is in one of the Fibonacci heaps, it takes an additional $O(\log n)$ to pull the new median out. This $O(\log n)$ charge occurs only once per median.

If there was a clean way to delete elements without damaging the nice Fibonacci heap complexity, we'd get down to $O(n \log m + m \log k)$, but I'm not sure if this is possible.