Откуда это вот берётся? :) Уже в куче статей в последнее время видел. Вы ж не лабораторную сдаёте и не курсовой, дык зачем этот официоз? В конце-концов, резюме, конечно, нужно, но чаще всего оно в таком виде подаётся, что ощущаешь себя преподом, принимающим списанную лабу.
Есть стандартная структура статей: вступление, основная часть и заключение.
Вступление нужно для того, чтобы дать высокоуровненвый обзор; чтобы читатель знал, на что обращать внимание.
А заключение нужно для того, чтобы еще раз напомнить основную идею, чтобы у вас сложилась цельная картина.
Кроме того, повторение--мать учения. Кажется, чтобы информация запомнилась, ее надо повторять через 20 минут, через пару чаов и через пару дней. Заключение как раз и соответствует первому повторению.
А я и не говорил, что заключение не нужно. Нужно, конечно же. Но вот стиль подачи у многих очень попахивает университетской банальностью. «Мы рассмотрели бла-бла-бла, из чего сделали вывод бла-бла-бла».
Мы ж на хабре, а не на сдаче курсовой, да? К чему все эти ненужности? Можно простым языком написать, а не используя этот банальный штамп, вбитый всем нам в голову в институтах.
очень похоже все это на immutable stack из блога Эрика Липперта. Там только упор делается не на возможность получения любой версии, а на неизменяемость объекта. Впрочем, по-моему получилось тоже самое. кстати там целый цикл великолепный статей про неизменяемость (immutability)
> Очевидно, что один запрос работает за O(1)
Мне не очевидно :) Вы не заострили внимание, что это зависит от того, как мы ищем i-й элемент. На вскидку массив даст константный доступ, но или нужно зарезервировать достаточно места, либо его расширять динамически. Хотя в алгоритмах я не разбираюсь, и буду рад, если укажите, где я ошибся :)
Да, пожалуй стоило упомянуть, что речь идет о структуре типа массив.
Насчет динамического расширенияВ данном случае можно зарезервировать изначально массив из 1-го элемента. Далее при каждом добавлении количество элементов растет, и когда оно становится равным зарезервированному количеству мы расширяем его в два раза. Каждое расширение работает за O от количества элементов на момент расширения.
Если мы добавили n элементов (округлим n вверх так, чтобы n = 2 ^ k), то суммируя количество операций расширения получим: 1 + 2 + 4 + 8 +… + 2 ^ k = 2 ^ (k + 1) = 2 * n, откуда получаем O(n). Таким образом количество операций, потраченных на расширение имеет тот же порядок, что и количество операций добавления, что не может не радовать.
Какое суммирование, вы о чем? Я нахожусь на n-ом шаге и до этого только добавлял, и мне нужно целиком скопировать весь массив. Это O(n)! В худшем случае, добавление займет O(n). Понятно, что в среднем, особенно если я буду часто удалять, это будет O(1), но это совсем не гарантировано.
Пусть вас не пугает то, что нужно скопировать весь массив. Выше я написал, почему если просуммировать все операции после добавления n элементов мы получим O(n) операций (кстати с небольшой константой), т.е. O(1) на одно добавление.
«Неизменяемая» (хотя это скорее immutable), «сохраняемая», не? Хотя вообще отличеие persistent jn immutable лишь в хранении указателей на старые версии насколько я понимаю.
Прочитав статью автора мне показалось, что его персистентный стек не что иное как immutable стэк. Беглое гугление привело меня в википедию, где написано «Persistent data structures are effectively immutable». То есть всякая persistent data structure является immutable. Но там не говорится, являются ли эти классы эквивалентными, то есть immutable -> persistent. Беглое гугление на этот вопрос ответа уже не дало, придумать immutable, но не persistent структуру мне не удалось. Поэтому я бы не стал утверждать, что «immutable лучше подходит» без должного обоснования.
у нас прямо конкурс цитат :) из статьи по моей ссылке: «A persistent data structure is not a data structure committed to persistent storage, such as a disk; this is a different and unrelated sense of the word „persistent.“» То есть слово одно, а значений два (минимум).
По прочтении статьи возникло стойкое желание прочитать кого-нибудь авторитетного по этим структурам данных. Гугл мямлит что-то о модуле для Перла. Не более.
На мой скорый взгляд, тут описано некий намек на реализацию дерева с числовым индексом в виде идентификатора узла.
Меня гложат большие сомнения по поводу адекватности производительности поиска по несбалансированному дереву по цифровому индексу (в статье — номер ревизии стека) для обращения к элементам дерева\стека.
Непонятен вопрос, как собрать все конечные состояния стека (а их может быть список)?
Как держать актуальный список головных ревизий? /Головная ревизия — последнее на текущий момент изменение всех веток развития стека/
Спасибо, полезная статья!
Можно привести еще несколько задач на эту структуру данных? И, если возможно, с контестером — чтобы можно было проверить решение.
Конкретно на стэк — не знаю. Это достаточно простая структура. Есть задача на персистентное дерево отрезков с ВКОШП-2010 (I, «Откаты»). Но она довольно сложная. Условия и тесты
Персистентные структуры, часть 1: персистентный стек