Структура поиска с историей (постоянство)

Мне нужна структура данных, похожая на карту (на C++) для хранения пар (Key,T) со следующей функциональностью:

  • Вы можете вставлять новые элементы (Key,T) в текущую структуру
  • Вы можете искать элементы на основе ключа в текущей структуре
  • Вы можете сделать «снимок» текущей версии структуры
  • Вы можете переключиться на одну из версий структур, с которых вы сделали снимок, и продолжить все операции оттуда.
  • Полностью удалить одну из версий

Что мне не нужно

  • Удаление элемента из конструкции
  • Слияние разных вариантов конструкции в один
  • Итерация по всем (или некоторым) элементам, хранящимся в настоящее время в структуре

Другими словами, у вас есть некоторая структура поиска, которую вы можете создать, но в любой момент вы можете перейти в историю и расширить более раннюю/другую версию структуры другим способом. Позже вы можете переключаться между этими разными версиями.

В моем проекте Key и T, скорее всего, будут целыми числами или значениями указателя, но не строками.

Основная цель состоит в том, чтобы уменьшить временную сложность; потребление пространства вторично (но также должно быть разумным). Чтобы уточнить, для меня log(N)+log(S) (где N-количество элементов, S-количество снимков) было бы достаточно, хотя чем быстрее, тем лучше :)

У меня есть приблизительное представление о том, как это реализовать --- например: будучи структурой бинарного дерева поиска, вставка нового элемента может клонировать путь от корня до места вставки, сохраняя при этом остальную часть дерева нетронутой. Переключение версий дерева было бы эквивалентно выбору другой версии корневого узла, для которого некоторые изменения просто не видны.

Однако, чтобы сделать это пользовательское дерево эффективным (например, самобалансирующимся), потребуются дополнительные усилия и тщательное программирование. Конечно, я могу сделать это сам, но, возможно, для этого уже существуют библиотеки?

Кроме того, вероятно, есть правильное имя для такого типа структуры данных, которое я просто не знаю, что делает мои поиски в Google (или SO-поиски) полными неудачами...

Спасибо за помощь!


person CygnusX1    schedule 21.06.2012    source источник
comment
Вы никогда не упоминали заказанные ключи; внутренняя структура может быть хеш-таблицей для более быстрого доступа. Дайте каждому указатель на его родительский снимок и выполните цепочку зондов для линейного времени в количестве снимков, но постоянное время в общем количестве элементов.   -  person phs    schedule 21.06.2012
comment
Чтобы помочь вам в поиске: постоянный — это термин, используемый для определения таких структур данных. Обычно это реализуется с использованием скрытого подсчета ссылок.   -  person Matthieu M.    schedule 21.06.2012
comment
Линейное время в подсчете моментальных снимков может быть слишком медленным. Я бы предпочел что-то около log(N) или даже полностью скрыть снимки.   -  person CygnusX1    schedule 21.06.2012


Ответы (1)


Я думаю, что вы ищете неизменяемую карту. Функциональные (или функциональные) языки программирования (такие как Haskell или Scala) имеют неизменяемые версии большинства контейнеров, которые вы найдете в STL. Такие операции, как вставка/удаление и т. д., затем возвращают копию карты (с сохранением оригинала) с копией, содержащей запрошенные вами изменения. Много работы ушло на проектирование структур данных, чтобы копии могли указывать на как можно большую часть исходной структуры данных, чтобы сократить время и сложность памяти для каждой операции.

Вы можете найти гораздо больше подробностей в книге, такой как эта: http://www.amazon.co.uk/Purely-Functional-Structures-Chris-Okasaki/dp/0521663504.

person Alex Wilson    schedule 21.06.2012
comment
Именно на это я и хотел ответить. Я просто добавлю OCaml в список языков, предоставляющих такие структуры. - person Thomash; 21.06.2012
comment
Хорошо иметь подсказки, но ОП попросил библиотеку, которая поддерживает это, чтобы избежать повторной реализации. Честно говоря, я не знаю, существует ли такая библиотека, так что подсказки, я думаю, хороши, но это не был основной вопрос. - person Matthieu M.; 21.06.2012
comment
Спасибо за предложение, я обязательно изучу эту книгу, возможно, она позволит мне лучше определить мои потребности и поможет в моей реализации... -ЕСЛИ- Я решу реализовать это сам. - person CygnusX1; 21.06.2012
comment
@Alex: Благодаря вам я нашел pdf-версию докторской диссертации Окасаки под тем же названием: cs.cmu.edu/~rwh/theses/okasaki.pdf - person CygnusX1; 21.06.2012
comment
@CygnusX1: Я хорошо поискал для вас существующие реализации, но, похоже, ничего не появилось. Существует FC++, который, похоже, сейчас устарел и никогда не имел древовидной структуры, но больше ничего не выявилось. Рада, что Вы нашли диссертацию! - person Alex Wilson; 21.06.2012
comment
Спасибо за ваше время, потраченное на его поиск. Я также наткнулся на ссылку FC++, здесь, на SO, но она была мертва. Обратите внимание, что это не обязательно должно быть дерево, если оно имеет разумную временную сложность, что-то около log(N)+log(S) (где S — количество моментальных снимков). - person CygnusX1; 21.06.2012