Хешинг із використанням дерев пошуку замість списків

11

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

insert,
find і
delete

стоїть на користь. середній випадок. Чи покращуються вони щодо списків?

— forrestGump
джерело

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

— Рафаель

4

Для списків, вставка, пошук та видалення знаходяться відповідно в , , . Відсортований список гірший. Сам бінарний пошук призначений для відсортованих масивів, в яких операції знаходяться в , , . Якщо ви хочете виконувати операції "вставки" та "видалення", то вам потрібно не просто двійковий пошук. $O(1)$ $O(n)$ $O(n)$ $O(n)$ $O(\log n)$ $O(n)$

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

— jmad
джерело

1

Це все правильно, але я не бачу, як це відповідає на поставлене питання.

— rgrig

Це був не той же питання , взагалі в той час. (Навіть історія редагування не має оригінального запитання. Дивно.) Я міг би оновити свою відповідь, але це стане непотрібним для Жилла.

— jmad

4

У гіршому випадку, якщо вам трапляється зберігати лише елементи з однаковими хеш-значеннями, хеш-таблиця зберігає кожен елемент у тому ж відрі. Якщо ви використовуєте списки для зберігання елементів відра, то пошук є в гіршому випадку (де - кількість елементів у таблиці - загальніше, - кількість елементів у найбільшому відрі), тому що вам потрібно пройти весь список, якщо ви шукаєте елемент, який відсутній у таблиці. Позитивний пошук (де ви знаєте, що елемент присутній) має таку ж складність: вам потрібен якщо ви шукаєте останній елемент списку. Видалення має однакову складність (вам потрібен $O(n)$ $n$ $n$ $n-1 = \Theta(n)$ $n-1$ пошук, якщо ви видаляєте останній елемент). Вставка також є якщо вам потрібно перевірити наявний елемент, або якщо ви дозволяєте дублікати (у цьому випадку ви можете вставити елемент на початку списку). $O(n)$ $O(1)$

При збалансованих деревах бінарного пошуку найгірша складність зводиться до , оскільки глибина збалансованого дерева пошуку зростає логарифмічно у розмірі дерева за визначенням балансування. $O(\log n)$

При середньому розподілі даних елементи розподіляються по різних відрах і виникає мало зіткнень, тому складність близька до незалежно від структури даних, що використовується у випадку зіткнень. $O(1)$

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

— Жил "ТАК - перестань бути злим"
джерело

2

"із середнім розподілом даних" слід читати "з достатньо випадковою хеш-функцією"

— JeffE