Яка оптимальна структура даних для дерева карт.

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

Наприклад, може бути кореневий вузол:

root = {'car':1, 'boat':2}

та 2 дітей, кожен з яких додає елемент до батьківської карти

child1 = {'car':1, 'boat':2, 'jet':35}
child2 = {'car':1, 'boat':2, 'scooter':-5}

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

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

Наївний підхід зберігав би щойно додані записи у карті на кожному вузлі, а потім переміщав би дерево, якщо нічого не знайдено. Мені це не подобається, оскільки це залежить від глибини дерева.

ds.data-structures tree hash-function

— фриз
джерело

тож кожен вузол представляє карту, яка уточнює карту, що зберігається в батьківському?

— Суреш Венкат

також, ви маєте на увазі карту в математичному чи картографічному сенсі?

— Суреш Венкат

Я маю на увазі карту в математичному / CS значенні. Наприклад, карта в STL.

— фріза

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

— Jukka Suomela

і щоб відповісти на перше запитання, кожен вузол уточнює карту в тому сенсі, що додається більше пар ключів / значень.

— фриз

Відповіді:

Ви ще не сказали, що таке запити, але я припускаю, що запит () бере у собі вузол і ключ і хоче, щоб асоційоване значення (або null, якщо такого значення не існує). У цьому випадку я думаю, що в цілому ви не можете зробити краще, ніж зберігати окрему карту на кожному вузлі. Розглянемо для прикладу дерево гусениць, де кожен вузол шляху має один вузол, підключений до нього, який розщедрився (загалом 2n вузлів). Корінь його на одному кінці шляху. Тепер припустимо, що розмір Всесвіту для ключів становить m. Для кожного відключеного вузла v та кожної з можливих клавіш m цей ключ може існувати або не існувати в v, і обидва відповідатимуть вашому обмеженню піддіаграми. Отже, є можливості для того, чи існує кожен ключ у кожному вузлі виделки, тож вам потрібно mn біт простору для зберігання потрібної інформації. $2^{mn}$

— Джелані Нельсон
джерело

Але цей приклад не показує, що ви повинні зберігати зайву інформацію (тобто, що вам потрібно дублювати записи кореневого вузла також у кожної дитини)!

— Jukka Suomela

Я збентежений. У дереві глибиною з вузлами зрозуміло, що ви не можете зберігати прив’язки в просторі. Чи показує ваш приклад щось більше?

1

$1$

n

$n$

m

$m$

o (m)

$o(m)$

— Раду ГРИГо

Перш за все, я думаю, що ви маєте на увазі під «картою» «словник» в мові TCS. По-друге, я не розумію фразу "в ідеалі пошук все-таки буде ", оскільки в словнику пошук займає час O (1) за допомогою різних хеш-таблиць. По-третє, ви не заявили, чи є проблема статичною чи динамічною; Я припускаю статичність. $O(\log N)$

Оптимальна складність цієї проблеми - пошук попередника), наприклад використанням Ван Емда Боаса. Це оптимально, якщо розмір слова дорівнює ; див. http://people.csail.mit.edu/mip/papers/pred/pred.pdf для оптимальних меж попередника. $\Theta($ $O(\lg\lg N)$ $\Theta(\lg n)$

Правильний спосіб атаки на проблему полягає в тому, щоб скласти одну глобальну хеш-таблицю та мати справу з ієрархією окремо для кожного ключа таблиці. Для одного ключа ми знаємо вузли, де він з’являється. Розгляньте порядок обходу дерева. Вузли, де з'являється , визначають інтервали в цьому порядку. Щоб визначити, чи знаходиться в хеш-таблиці деякого вузла , ви повинні запитати, чи зашиває який-небудь сегмент, як визначено вище. Це легко зробити за допомогою попередника пошуку, де ми будуємо таблицю попередника для всіх кінцевих точок інтервалу. $x$ $x$ $x$ $v$ $v$

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

— Міхай
джерело