Імовірнісний набір без помилкових позитивів?

Отже, фільтри Bloom досить круті - це набори, які підтримують перевірку членства, не маючи помилкових негативів, але малий шанс помилкового позитиву. Нещодавно я хотів "фільтру Блюма", який гарантує протилежне: ніяких помилкових позитивів, але потенційно помилкових негативів.

Моя мотивація проста: враховуючи величезний потік предметів для обробки (з дублікатами), ми хотіли б уникати обробки предметів, які ми бачили раніше. Обробляти дублікат не завадить, це лише марна трата часу. Але, якби ми нехтували обробкою елемента, це було б катастрофічно. За допомогою "зворотного фільтра Блюма" можна було зберігати побачені предмети з невеликим накладними витратами, а також уникати обробки дублікатів з високою ймовірністю, перевіряючи приналежність до набору.

Але я, здається, не можу знайти нічого подібного. Найближчі я знайшов - це " ретушовані фільтри Блюма ", які дозволяють торгувати вибраними помилковими позитивами для більш високої помилкової негативної ставки. Я не знаю, наскільки добре працює їх структура даних, коли потрібно видалити всі помилкові позитиви.

Хтось бачив щось подібне? :)

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

Відповідь на це питання - «ні». Щоб зрозуміти, чому, ми можемо подумати про надзвичайний випадок, і як працював звичайний фільтр цвітіння, порівняно з теоретичним фільтром цвітіння "Світ Bizzaro", який ми можемо назвати "похмурим фільтром".

Що стосується фільтра цвітіння, це те, що ви можете робити однобічні тести на приналежність елементів (з помилковими позитивами), використовуючи структуру даних, яка має фіксований розмір щодо ймовірності помилки та кількості елементів, що зберігаються. У розмірах цих елементів самі по собі не мають значення. Наприклад, якби у нас був фільтр цвітіння, встановлений для зберігання до 1000 предметів з помилкою менше 3%, то ми могли б зберігати 1000 трохи різних версій всього корпусу Вікіпедії, з однією буквою, зміненою в кожній, і ми все одно отримуємо потрібні нам показники, і структура даних була б дуже крихітною (менше кілобайт). Звичайно, обчислення цих хешей буде складним завданням, але принцип все-таки дотримується.

А тепер подумайте про збереження тих самих масивних рядків у похмурому фільтрі! Зараз ми можемо мати лише помилкові негативи. Тож якщо ми скажемо "так, ця версія всього корпусу Вікіпедії є в цьому наборі", то ми маємо бути абсолютно в цьому відношенні. Це означає, що хешування не допоможе нам, оскільки завжди буде якийсь інший рядок, який хеширує однакове значення. Єдиний спосіб сказати "так" і бути впевненим - це збереження цілого рядка або деяких еквівалентних даних однакової довжини. Ми завжди не могли його зберігати і сказати «ні», але з часом рівень помилок нас наздожене. Найкраще, що ми могли зробити, - це стиснення, зменшення розміру структури до продукту ентропії збережених даних та бажаної точності.

Тож, на жаль, фільтр похмурості не існує. Кешування - єдине рішення, але насправді це не протилежне фільтру розцвітання, оскільки його розмір буде пропорційним твору кількості інформації, що зберігається, та бажаної швидкості точності фільтра. Звичайно, у багатьох реальних сценаріях великі дані можуть бути представлені ідентифікатором, тому кешування може бути цілком прийнятним. Але він принципово відрізняється від фільтра могутнього цвітіння.

Ви просто хочете кеш , але думаєте про це дивним чином.

ВІДПОВІДАЛЬНІСТЬ: Я не знавець кеш-пам'яті, тому це може бути наївною ідеєю, а також може бути відомою ідеєю, про яку я ніколи раніше не чув. Тож вибачте, якщо я не процитую його посилання (якщо воно існує); і, будь ласка, повідомте мене, чи є посилання на нього, щоб відредагувати публікацію та додати її. (Я підозрюю, що це може мати посилання, оскільки це так інтуїтивно).

$c$$c$

Я використовував дерева AVL (а іноді і червоно-чорні) з частковими елементами, щоб діяти як фільтр без помилкових негативів. Використовуйте лише перші X байти елемента, вставляючи або запитуючи дерево. Оскільки структура даних не є імовірнісною за формою, не існує ризику помилково-позитивного при бітовому зіткненні. І на відміну від кешування всього елемента, такий підхід дає вам максимально можливий простір. Ви можете налаштувати швидкість помилкових позитивів, розглядаючи різні довжини префікса / глибини дерева порівняно з вартістю помилкових позитивів та місцями.

Я думаю, що можна довести нижню межу, заявивши, що вищезазначена структура даних не може існувати. В основному, якщо структура даних використовує m біт, то фіксований бітовий вектор (подання вводу) може відповідати максимум (((un) + n eps) \ select (un)) наборам аргументом підрахунку. Враховуючи, що 2 ^ m разів це число повинно бути принаймні (u \ select n) (усі множини повинні бути представлені), ми отримуємо нижню межу, яка в основному дуже близька до точного зберігання множини S.