Нетривіальний алгоритм для обчислення медіани розсувного вікна

Мені потрібно обчислити медіану бігу:

Вхід: $n$ , $k$ , вектор $(x_1, x_2, \dotsc, x_n)$ .
Вихід: вектор $(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$ ; сортувати кожну частину (слідкуючи за вихідними положеннями кожного елемента); а потім використовувати кусково відсортований вектор, щоб ефективно знайти працюючі медіани без будь-яких допоміжних структур даних? Звичайно, це все-таки буде $O(n \log k)$ , але на практиці сортування масивів, як правило, відбувається набагато швидше, ніж підтримка дерев пошуку.

Редагування 2: Саїд хотів побачити деякі причини, чому я вважаю, що сортування відбувається швидше, ніж операції з пошуковим деревом. Ось дуже швидкі орієнтири, для $k = 10^7$ , $n = 10^8$ :

≈ 8s: сортування векторів з елементами кожен $n/k$ $k$
≈ 10s: сортування вектора з елементами $n$
≈ 80-ті: вставок та видалень у хеш-таблиці розміром $n$ $k$
≈ 390s: вставок та вилучень у збалансованому дереві пошуку розміром $n$ $k$

Хеш-таблиця існує просто для порівняння; це не має прямого використання в цій програмі.

Підсумовуючи, ми маємо майже різницю в коефіцієнт 50 у ефективності сортування та збалансованих операцій із пошуковим деревом. І все стає набагато гірше, якщо ми збільшимо . $k$

(Технічні деталі: Дані = випадкові 32-бітні цілі числа. Комп'ютер = типовий сучасний ноутбук. Тестовий код був написаний на C ++, використовуючи стандартні підпрограми бібліотеки (std :: сортування) та структури даних (std :: multiset, std :: unsorted_multiset) Я використав два різних компілятори C ++ (GCC та Clang) та дві різні реалізації стандартної бібліотеки (libstdc ++ та libc ++). Традиційно std :: multiset реалізований як високооптимізований червоно-чорний дерево.)

ds.algorithms ds.data-structures lower-bounds

— Юкка Суомела
джерело

Я не думаю, що вам вдасться вдосконалити

. Причина в тому, якщо ви подивитеся на вікно

, ви ніколи не можете виключати жодне з чисел

n l o g k

$nlogk$

x_{t}, . . ., x_{t + k - 1}

$x_t,...,x_{t+k-1}$

це медіани майбутнього вікна. Це означає, що в будь-який час ви повинні тримати принаймні

x_{t + \frac{k}{2}}, . . ., x_{t + k - 1}

$x_{t+\frac{k}{2}},...,x_{t+k-1}$

цілих числа в структурі даних, і вона, здається, не оновлюється за менший час журналу.

\frac{k}{2}

$\frac{k}{2}$

— РБ

Ваш тривіальний алгоритм мені здається

не

, я щось неправильно зрозумів? І я думаю, що через це у вас проблема з великим

, інакше логарифмічний фактор - це ніщо в практичних програмах, також немає великої прихованої константи в цьому алгоритмі.

O ((n - k) \cdot k \cdot \log k)

$O((n-k)\cdot k \cdot \log k)$

O (n \log k)

$O(n \log k)$

k

$k$

— Саїд

@Saeed: у тривіальному алгоритмі ви обробляєте елементи по черзі; на кроці

ви додаєте

до дерева пошуку, а (якщо

) ви також видаляєте

з дерева пошуку. Це

кроків, кожен з яких займає час

i

$i$

x_{i}

$x_i$

i > k

$i > k$

x_{i - k}

$x_{i-k}$

n

$n$

O (\log k)

$O(\log k)$

— Jukka Suomela

Отже, ви маєте на увазі, що у вас збалансоване дерево пошуку, а не випадкове дерево пошуку?

— Саїд

@Saeed: Зверніть увагу, що у своїх тестах я навіть не намагався знайти медіанів. Я тільки зробив

вставок і

вилучень у дереві пошуку розміром

, і ці операції гарантовано займуть час

. Вам просто потрібно прийняти, що операції з пошуковим деревом на практиці дуже повільні, порівняно з сортуванням. Це ви побачите легко, якщо спробуєте написати алгоритм сортування, який працює, додаючи елементи до збалансованого дерева пошуку - це, безумовно, працює в

час, але це буде смішно повільно на практиці, а також витрачає багато пам'яті.

n

$n$

n

$n$

k

$k$

O (\log k)

$O(\log k)$

O (n \log n)

$O(n \log n)$

— Jukka Suomela

Відповіді:

Ось нижня межа від сортування. Враховуючи набір вхідного сигналу довжини який потрібно сортувати, створіть вхід до вашої середньої задачі, що складається з копій числа, меншого від мінімуму , потім самого , потім копій числа, більшого ніж максимум , а задаємо . Ходові медіани цього входу такі ж , як в відсортованому порядку . $S$ $n$ $n-1$ $S$ $S$ $n-1$ $S$ $k=2n-1$ $S$

Отже, для порівняльної моделі обчислення необхідний час . Можливо, якщо ваші дані є цілими числами, а ви використовуєте цілі алгоритми сортування, ви можете зробити краще. $\Omega(n\log n)$

— Девід Еппштейн
джерело

Ця відповідь насправді змушує мене замислитись, чи справедливим є і зворотне: з огляду на ефективний алгоритм сортування, чи отримуємо ми ефективний алгоритм роботи медіани? (Наприклад, чи ефективний алгоритм сортування цілих чисел має на увазі ефективний алгоритм середньої алгоритму виконання цілих чисел? Або алгоритм сортування, що діє на IO, забезпечує медіа-алгоритм ефективного виконання IO?)

— Jukka Suomela

Ще раз, велике спасибі за вашу відповідь, це дійсно поставило мене на правильний шлях і надихнуло на алгоритм медіанного фільтра на основі сортування! Врешті-решт, мені вдалося знайти документ з 1991 року, який в основному представляв такий же аргумент, що і ви, що ви даєте тут, і Пат Морін дав вказівник на інший відповідний документ від 2005 року; див. реф. [6] та [9] тут .

— Юкка Суомела

Редагувати: Цей алгоритм представлений тут: http://arxiv.org/abs/1406.1717

Так, для вирішення цієї проблеми достатньо виконати такі операції:

Сортуйте вектори, кожен з елементів. $n/k$ $k$
Виконайте лінійний час після обробки.

Дуже приблизно, ідея така:

Розглянемо два сусідні блоки введення, і , обидва з елементами; нехай елементи будуть і у порядку появи у вхідному векторі . $a$ $b$ $k$ $a_1, a_2, ..., a_k$ $b_1, b_2, ..., b_k$ $x$
Сортуйте ці блоки та вивчіть ранг кожного елемента в блоці.
Розширіть вектори і допомогою покажчиків попередника / наступника, щоб, слідуючи ланцюжкам вказівників, ми могли переміщувати елементи у порядку зростання. Таким чином, ми побудували подвійно пов'язані списки і . $a$ $b$ $a'$ $b'$
Один за іншим, видалити всі елементи з пов'язаного списку , в зворотному порядку появи . Щоразу, коли ми видаляємо елемент, пам’ятайте, що було його наступником та попередником на момент видалення . $b'$ $b_k, b_{k-1}, ..., b_1$
Тепер підтримуйте "середні покажчики" і які вказують на списки і відповідно. Initialise до середньої точки , і Initialise до хвоста порожнього списку . $p$ $q$ $a'$ $b'$ $p$ $a'$ $q$ $b'$
Для кожного : $i$
- Видалення зі списку (це час, просто видаліть з пов'язаного списку). Порівняйте з елементом вказав на , щоб побачити , якщо ми видалили до або після того, як . $a_i$ $a'$ $O(1)$ $a_i$ $p$ $p$
- Поставте назад до списку у його початковому положенні (це час, ми запам'ятали попередника і наступника ). Порівняйте з елементом, вказаним щоб побачити, чи додали ми елемент до або після . $b_i$ $b'$ $O(1)$ $b_i$ $b_i$ $q$ $q$
- Оновіть покажчики і так, що медіана об'єднаного списку або на або на . (Це час, просто дотримуйтесь пов'язаних списків один або два кроки, щоб все виправити. Ми будемо відстежувати, скільки предметів до / після і у кожному списку, і ми будемо підтримувати інваріант, що обидва і вказують на елементи, максимально наближені до медіани.) $p$ $q$ $a' \cup b'$ $p$ $q$ $O(1)$ $p$ $q$ $p$ $q$

Зв'язані списки - це просто -елементні масиви індексів, тому вони легкі (за винятком того, що локальність доступу до пам'яті погана). $k$

Ось приклад реалізації та орієнтири:

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

Ось графік часу роботи (для ): $n \approx 2\cdot 10^6$

Синій = сортування + післяобробка, . $O(n \log k)$
Зелений = підтримка двох купи, , реалізація від https://github.com/craffel/median-filter $O(n \log k)$
Червоний = підтримують два дерева пошуку, . $O(n \log k)$
Чорний = підтримувати відсортований вектор, . $O(n k)$
Вісь X = розмір вікна ( ). $\approx k/2$
Вісь Y = час роботи в секундах.
Дані = 32-бітні цілі числа та випадкові 64-бітні цілі числа з різних розподілів.

running times

— Юкка Суомела
джерело

З огляду на обмеженість Девіда, навряд чи можна зробити гірший випадок, але є кращі алгоритми, що відрізняються від виходу. Зокрема, якщо у кількості медіанів у результаті, ми можемо вирішити задачу за час . $m$ $O(n \log m + m \log n)$

Для цього замініть збалансоване бінарне дерево збалансованим бінарним деревом, що складається лише з тих елементів, які були медіанами в минулому, плюс два купи Фібоначчі між кожною парою попередніх медіанів (по одному для кожного напрямку), плюс рахується, щоб ми могли знайдіть, яка купка Фібоначчі містить певний елемент у порядку. Не заважайте ніколи видаляти елементи. Коли ми вставимо новий елемент, ми можемо оновити структуру даних за час . Якщо нові підрахунки вказують на те, що медіана знаходиться в одній із куб Фібоначчі, для витягування нової медіани потрібно додаткове . Це $O(\log m)$ $O(\log n)$ $O(\log n)$ заряд відбувається лише один раз за медіану.

$O(n \log m + m \log k)$

— Джеффрі Ірвінг
джерело

Oops, this doesn't work as written, since if you don't delete elements the counts won't reflect the new window. I'm not sure if it can be fixed, but I will leave the answer in case there is a way.

— Geoffrey Irving

Тому я думаю, що цей алгоритм може насправді зайняти

O (n \log m)

$O(n \log m)$ якщо ви видалите вузли з куб Фібоначчі, оскільки глибина кучі Фібоначчі збільшується лише тоді, коли викликається min-min. Хтось знає приємні межі складності купи Фібоначчі з урахуванням кількості видалених хвилин дзвінків?

— Джеффрі Ірвінг

сторона Примітка: Питання не зрозуміле, структура даних не визначена, ми просто знаємо щось дуже розпливчасте. як ти хочеш вдосконалити щось, чого не знаєш, що це? як ти хочеш порівняти свій підхід?

— Саїд

I apologize for the incomplete work. I've asked the concrete question needed to fix this answer here: cstheory.stackexchange.com/questions/21778/…. If you think it's appropriate I can remove this answer until the secondary question is resolved.

— Geoffrey Irving