Ефективне видалення дублікатів та з низькою витратою пам’яті

Я хочу ефективно фільтрувати список цілих чисел для дублікатів таким чином, що потрібно зберігати лише отриманий набір.

Один із способів цього можна побачити:

• ми маємо діапазон цілих чисел $S = \{1, \dots{}, N\}$ з $N$ великий (скажімо $2^{40}$)
• у нас є функція $f : S \to S$ нібито з багатьма зіткненнями (зображення рівномірно розподілені в $S$)
• тоді нам потрібно зберігати $f[S]$, це є $\{f(x) | x \in S\}$

Я маю досить точну (імовірнісну) оцінку того, що $|f[S]|$ є, і тому може виділяти структури даних заздалегідь (скажімо $|f[S]| \approx 2^{30}$).

У мене було кілька ідей, але я не впевнений, що було б найкращим підходом:

• про біт не виникає сумніву, оскільки вхідний набір не вписується в пам'ять.
• хеш-таблиця, але (1) їй потрібна деяка об'єм пам'яті, скажімо, 150% $|f[S]|$ та (2) таблицю слід досліджувати, коли її будують, що вимагає додаткового часу через об'єм пам'яті.
• сорт "на льоту", бажано з $O(N)$складність (сортування порівняння). З цього приводу я не впевнений, яка головна різниця між сортуванням відра і спалахом .
• простий масив з двійковим деревом пошуку, але для цього потрібно $O(N \log |f[S]|)$ час.
• можливо, використання фільтрів Bloom або подібної структури даних може бути корисним для розслаблення (з помилковими позитивами) проблеми.

Деякі питання щодо stackoverflow, схоже, вирішують подібні речі ( /programming/12240997/sorting-array-in-on-run-time , /programming/3951547/java -array-find-дублікати ), але, схоже, жоден не відповідає моїм вимогам.

Чому б не бен і ланцюжок?

Ідея полягає в тому, щоб зберігати додатні цілі числа, що можуть бути представлені $n = k+m$ біти в масиві $A$ з $2^k$ записи, що представляють діапазони значень: запис $A[y]$, $y \ge 0$, представляє діапазон $[2^m y, 2^m(y+1)-1]$. Для будь-якого$1 \le x \lt 2^n$ ми можемо написати $x = 2^m y + z$ де $y$ має $k$ біт і $z$ має $m$біт. Спробуйте зберігати$z$ (не $x$!) за місцезнаходженням $y$:

• Коли $A[y]=z$ вже нічого не робіть: $x$ є дублікатом.

• Коли $A[y]$ неініціалізований, зберігати $z$ у $A[y]$.

• В іншому випадку зберігайте індекс в окремому масиві, який використовується для ланцюжка $z$'s (які зіткнулися в $y$) у пов'язаних списках. Вам доведеться шукати лінійно через список, очолюваний ним$A[y]$ і, залежно від того, що розкриває пошук, потенційно вставити $z$ в список.

В кінці, $f(S)$ легко відновити, переглянувши через ініціалізовані записи $A$ і - шляхом об'єднання двох біткових рядків - перескладання кожного $z$ знайдено за адресою $y$ (безпосередньо або всередині ланцюга, на який посилається) у вихідне значення $x = 2^m y + z$.

Коли розподіл близький до рівномірного і $2^k$ перевищує $N$, ланцюг не буде сильним (це можна оцінити звичайними способами), і ланцюги, як правило, будуть короткими. Коли розподіл є неоднорідним, алгоритм все ще працює, але може досягти квадратичного моменту часу. Якщо така можливість є, використовуйте щось більш ефективне, ніж ланцюги (і заплатите трохи накладні витрати на зберігання).

Необхідне місце для зберігання - не більше $2^n$ біт для $A$ і $2^{2k}$ біти для ланцюгів (припускаючи $m \le k$). Це саме простір, необхідний для зберігання$2^k$ значення $n$біт кожен. Якщо ви впевнені в рівномірності, ви можете виділити сховище для ланцюгів. Якщо неоднорідність є можливою, можливо, ви захочете збільшити$k$ і повністю відстоюють ланцюгове зберігання.

Альтернативний спосіб думати про це рішення є те , що вона є хеш - таблиця з особливо хорошою хеш - функції (взяти$k$ найбільш значущі біти), і через це нам потрібно зберігати лише найменші значущі $m=n-k$ біти в таблиці.

Існують способи перекриття пам’яті для ланцюгів із накопичувачем для $A$ але це, здається, не варто турбувати, тому що це не заощадить багато (припустимо $m$ набагато менше, ніж $k$) простір і ускладнить розробку, налагодження та підтримку коду.