Яка структура даних дозволила б ефективно зберігати цілі діапазони?

Мені потрібно зберегти колекцію цілих чисел у межах від 0 до 65535, щоб я міг швидко зробити наступне:

• Вставте нове ціле число
• Вставте діапазон суміжних цілих чисел
• Видаліть ціле число
• Видаліть усі цілі числа нижче цілого числа
• Перевірте, чи є ціле число

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

{ 121, 122, 123, 124, 3201, 3202, 5897, 8912, 8913, 8914, 18823, 18824, 40891 }

Найпростіший підхід полягає лише у використанні збалансованого двійкового дерева, такого як C ++ std :: set, однак, використовуючи це, я не використовую той факт, що у мене часто буває кількість чисел. Можливо, було б краще зберігати колекцію асортиментів? Але це означає, що діапазон повинен бути розбитим, якщо ціле число в його середині буде видалено, або з'єднане разом, якщо заповнений пробіл між двома діапазонами.

Чи існують якісь структури даних, які добре підходили б для цієї проблеми?

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

У цій структурі даних ви можете підтримувати всі ваші операції в час, де - кількість інтервалів. Оскільки ми гарантуємо , я б очікував, що це буде досить ефективно. (Зокрема, так, ви можете розділити інтервал на дві частини або об'єднати два суміжні інтервали в один інтервал за час.)n n ≤ 65535 O ( lg n $O(\lg n)$$n$$n\le 65535$$O(\lg n)$

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

Крім того, намагаючись придумати проект проблеми, потрібно спочатку дуже добре зрозуміти проблему і задати багато додаткових питань. Відповідні питання у цьому випадку, мабуть, будуть (не в певному порядку):

• Чи повинні всі ці операції бути однаково швидкими, або якісь важливіші за інші?
• Чи є інші міркування?
• Чи пам’ять взагалі хвилює?
• Чи викликає занепокоєння можливість виконувати вставки, видалення та пошук з декількох потоків?
• Чи основне навантаження зосереджено на вставці? Видалення? Дивлячись?

По-друге, якщо ваш проблемний домен насправді є то ця дискусія видається просто дурною. Чи справді необхідний розумний, химерний алгоритм ? Особливо, коли простий масив є відмінним варіантом, що охоплює одиничні цілі операції в постійному часі, операції діапазону в лінійному часі і витрати лінійного простору?$[0, 65535]$

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

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

Якщо це насправді не ваша проблема і є інші міркування, які ви не ретранслювали (наприклад, домен насправді не є і ви намагалися спростити проблему, про яку ви питали), тоді вам знадобиться щоб знову задати своє запитання, цього разу розповівши нам про актуальну проблему.$[0, 65535]$

Ви можете розглянути структуру даних Integer, наприклад, дерево Ван Емде Боаса . Структура даних Integer працює у фіксованому всесвіті . Деякі з згаданих вами операцій можна здійснити дуже ефективно. Зокрема, вставлення, видалення та запит на один елемент виконується в . Інші операції (групове вставлення / видалення) можуть бути дорожчими, однак, використовуючи біттрики на дереві Van Emde Boas, ви повинні мати можливість отримати прискорення на коефіцієнт приблизно від розміру слова вашої системи.O ( журнал журналу u $\mathcal{U}=\{0,\ldots,u-1\}$$O(\log \log u)$

Залежно від структури ваших даних може бути багато розумних альтернатив, як зберігати свої дані.