Persistent data structure: Difference between revisions

Revision as of 04:21, 22 April 2024

Latest revision as of 07:10, 21 June 2025

(13 intermediate revisions by 4 users not shown)

Line 14:

A type of data structure where user may query any version of the structure but may only update the latest version.

An ephermeralephemeral data structure can be converted to partially persistent data structure using a few techniques.

One of the technique is by using randomized version of Van Emde Boas Tree which is created using dynamic perfect hashing. This data structure is created as follows:

Line 27:

=== Copy-on-write ===

One method for creating a persistent data structure is to use a platform provided ephemeral data structure such as an [[Mutable array|array]] to store the data in the data structure and copy the entirety of that data structure using [[Copy-on-write|copy-on-write semantics]] for any updates to the data structure. This is an inefficient technique because the entire backing data structure must be copied for each write, leading to worst case <math>O(n·\cdot m)</math> performance characteristics for ''m'' modifications of an array of size ''n''.{{citation needed|date=May 2019}}

[[Copy-on-write]] memory management can reduce the price for an update from <math>\Theta(n)</math> to <math>O(Bu)</math>, where ''B'' is the memory block size and ''u'' the number of pages updated in an operation.{{citation needed|date=May 2019}}

===Fat node===

Line 33 ⟶ 34:

====Complexity of fat node====

With using fat node method, it requires O(1) space for every modification: just store the new data. Each modification takes O(1) additional time to store the modification at the end of the modification history. This is an [[Amortized analysis|amortized time]] bound, assuming modification history is stored in a growable [[Array data structure|array]]. At [[access time]], the right version at each node must be found as the structure is traversed. If "''m"'' modifications were to be made, then each access operation would have <math>O(\log m)</math> slowdown resulting from the cost of finding the nearest modification in the array. Alternatively, one can employ the [[van Emde Boas tree]] at each node (possibly the space-efficient version using hashing) to reduce the time for an access to <math>O(\log\log m)</math> at the cost of increasing update time to <math>O(\log\log m)</math>.

===Path copying===

This method assumes that the data structure is a linked graph of nodes.

WithOn theupdate, patha copyingcopy methodis a copymade of all nodes is made on the path to any node which is about to be modified. These changes must then be [[Fractional cascading|cascaded]] back through the data structure: all nodes that pointed to the old node must be modified to point to the new node instead. These modifications cause more cascading changes, and so on, until the root node is reached.

====Complexity of path copying====

Line 42 ⟶ 44:

===A combination===

Driscoll, Sarnak, [[Daniel Sleator|Sleator]], [[Robert Tarjan|Tarjan]] came up<ref name=Driscoll /> with a way to combine the techniques of fat nodes and path copying, achieving O(1) access slowdown and O(1) modificationamortized overhead in space and time complexityper modification. Their method assumes a linked data structure with at most ''d'' incoming pointers to each node, where ''d'' is a known constant.

In each node, one modification box is stored. This box can hold one modification to the node—either a modification to one of the pointers, or to the node's key, or to some other piece of node-specific data—and a timestamp for when that modification was applied. Initially, every node's modification box is empty.

Line 53 ⟶ 55:

====Complexity of the combination====

Time and space for modifications require amortized analysis. A modification takes O(1) amortized space, and O(1) amortized time. To see why, use a [[Potential method|potential function]] ''ϕ'', where ''ϕ''(T) is the number of full live nodes in T . The live nodes of T are just the nodes that are reachable from the current root at the current time (that is, after the last modification). The full live nodes are the live nodes whose modification boxes are full.

Each modification involves some number of copies, say ''k'', followed by 1 change to a modification box. Consider each of the ''k'' copies. Each costs O(1) space and time, but decreases the potential function by one. (First, the node to be copied must be full and live, so it contributes to the potential function. The potential function will only drop, however, if the old node isn't reachable in the new tree. But it is known that it isn't reachable in the new tree—the next step in the algorithm will be to modify the node's parent to point at the copy. Finally, it is known that the copy's modification box is empty. Thus, replaced a full live node has been replaced with an empty live node, and ''ϕ'' goes down by one.) The final step fills a modification box, which costs O(1) time and increases ''ϕ'' by one.

Putting it all together, the change in ''ϕ'' is ΔϕΔ''ϕ'' =1−1 − ''k''. Thus, the algorithm takes O(''k'' +ΔϕΔ''ϕ'')= O(1) space and O(''k'' +ΔϕΔ''ϕ'' +1) = O(1) time

==Generalized form of persistence==

Line 86 ⟶ 88:

*CHANGE-EDGE: There are two cases to consider. The first case occurs when there is still at least one empty row in the table. In this case one credit is used to the newly inserted row. The second case occurs when the table is full. In this case the old table becomes inactive and the <math>d+1</math> credits are transformed to the new table in addition to the one credit acquired from calling the CHANGE-EDGE. So in total we have <math>d+2</math> credits. One credit will be used for the creation of the new table. Another credit will be used for the new row added to the table and the {{mvar|d}} credits left are used for updating the tables of the other vertices that need to point to the new table. We conclude that the invariant is maintained.

*CHANGE-LABEL: It works exactly the same as CHANGE-EDGE.

As a summary, we conclude that having <math>n_{1}</math> calls to CREATE_NODE and <math>n_{2}</math> calls to CHANGE_EDGE will result in the creation of <math>2\cdot n_{1}+n_{2}</math> tables. Since each table has size <math>O(d)</math> without taking into account the recursive calls, then filling in a table requires <math>O(d^{2}dc)</math> where the additional d factor comes from updating the inedges at other nodes. Therefore, the amount of work required to complete a sequence of operations is bounded by the number of tables created multiplied by <math>O(d^{2}dc)</math>. Each access operation can be done in <math>O(Log\log(d))</math> and there are <math>{{mvar|m</math>}} edge and label operations, thus it requires <math>m\cdot O(Log\log(d))</math>. We conclude that There exists a data structure that can complete any <math>{{mvar|n</math>}} sequence of CREATE-NODE, CHANGE-EDGE and CHANGE-LABEL and ''m'' access operations in <math>O(n\cdot d^{2}dc)+m\cdot O(Log\log(d))</math>.

==Applications of persistent data structures==

===Next element search or point ___location===

One of the useful applications that can be solved efficiently using persistence is the Next Element Search. Assume that there are <math>{{mvar|n</math>}} non intersecting line segments that don't cross each other that are parallel to the x-axis. We want to build a data structure that can query a point <math>{{mvar|p</math>}} and return the segment above <math>{{mvar|p</math>}} (if any). We will start by solving the Next Element Search using the naïve method then we will show how to solve it using the persistent data structure method.

====Naïve method====

We start with a vertical line segment that starts off at infinity and we sweep the line segments from the left to the right. We take a pause every time we encounter an end point of these segments. The vertical lines split the plane into vertical strips. If there are <math>{{mvar|n</math>}} line segments then we can get <math>2\cdot n+1</math> vertical strips since each segment has <math>{{val|2</math>}} end points. No segment begins and ends in the strip. Every segment either it doesn't touch the strip or it completely crosses it. We can think of the segments as some objects that are in some sorted order from top to bottom. What we care about is where the point that we are looking at fits in this order. We sort the endpoints of the segments by their <math>{{mvar|x</math>}} coordinate. For each strip <math>s_{i}</math>, we store the subset segments that cross <math>s_{i}</math> in a dictionary. When the vertical line sweeps the line segments, whenever it passes over the left endpoint of a segment then we add it to the dictionary. When it passes through the right endpoint of the segment, we remove it from the dictionary. At every endpoint, we save a copy of the dictionary and we store all the copies sorted by the <math>{{mvar|x</math>}} coordinates. Thus we have a data structure that can answer any query. In order to find the segment above a point <math>{{mvar|p</math>}}, we can look at the <math>{{mvar|x</math>}} coordinate of <math>{{mvar|p</math>}} to know which copy or strip it belongs to. Then we can look at the <math>{{mvar|y</math>}} coordinate to find the segment above it. Thus we need two binary searches, one for the <math>{{mvar|x</math>}} coordinate to find the strip or the copy, and another for the <math>{{mvar|y</math>}} coordinate to find the segment above it. Thus the query time takes <math>O(Log\log(n))</math>. In this data structure, the space is the issue since if we assume that we have the segments structured in a way such that every segment starts before the end of any other segment, then the space required for the structure to be built using the naïve method would be <math>O(n^{2})</math>. Let us see how we can build another persistent data structure with the same query time but with a better space.

====Persistent data structure method====

We can notice that what really takes time in the data structure used in the naïve method is that whenever we move from a strip to the next, we need to take a snap shot of whatever data structure we are using to keep things in sorted order. We can notice that once we get the segments that intersect <math>s_{i}</math>, when we move to <math>s_{i+1}</math> either one thing leaves or one thing enters. If the difference between what is in <math>s_{i}</math> and what is in <math>s_{i+1}</math> is only one insertion or deletion then it is not a good idea to copy everything from <math>s_{i}</math> to <math>s_{i+1}</math>. The trick is that since each copy differs from the previous one by only one insertion or deletion, then we need to copy only the parts that change. Let us assume that we have a tree rooted at <math>{{mvar|T</math>}}. When we insert a key <math>{{mvar|k</math>}} into the tree, we create a new leaf containing <math>{{mvar|k</math>}}. Performing rotations to rebalance the tree will only modify the nodes of the path from <math>{{mvar|k</math>}} to <math>{{mvar|T</math>}}. Before inserting the key <math>{{mvar|k</math>}} into the tree, we copy all the nodes on the path from <math>{{mvar|k</math>}} to <math>{{mvar|T</math>}}. Now we have 2 versions of the tree, the original one which doesn't contain <math>{{mvar|k</math>}} and the new tree that contains <math>{{mvar|k</math>}} and whose root is a copy of the root of <math>{{mvar|T</math>}}. Since copying the path from <math>{{mvar|k</math>}} to <math>{{mvar|T</math>}} doesn't increase the insertion time by more than a constant factor then the insertion in the persistent data structure takes <math>O(Log\log(n))</math> time. For the deletion, we need to find which nodes will be affected by the deletion. For each node <math>{{mvar|v</math>}} affected by the deletion, we copy the path from the root to <math>{{mvar|v</math>}}. This will provide a new tree whose root is a copy of the root of the original tree. Then we perform the deletion on the new tree. We will end up with 2 versions of the tree. The original one which contains <math>{{mvar|k</math>}} and the new one which doesn't contain <math>{{mvar|k</math>}}. Since any deletion only modifies the path from the root to <math>{{mvar|v</math>}} and any appropriate deletion algorithm runs in <math>O(Log\log(n))</math>, thus the deletion in the persistent data structure takes <math>O(Log\log(n))</math>. Every sequence of insertion and deletion will cause the creation of a sequence of dictionaries or versions or trees <math>S_{1}, S_{2}, \dots S_{i}</math> where each <math>S_{i}</math> is the result of operations <math>S_{1}, S_{2}, \dots S_{i}</math>. If each <math>S_{i}</math> contains <math>{{mvar|m</math>}} elements, then the search in each <math>S_{i}</math> takes <math>O(Log\log(m))</math>. Using this persistent data structure we can solve the next element search problem in <math>O(Log\log(n))</math> query time and <math>O(n\cdot Log\log(n))</math> space instead of <math>O(n^{2})</math>. Please find below the source code for an example related to the next search problem.

==Examples of persistent data structures==

[[Purely functional data structure]] are automatically persistent.

Perhaps the simplest persistent data structure is the [[Linked list|singly linked list]] or ''cons''-based list, a simple list of objects formed by each carrying a [[reference]] to the next in the list. This is persistent because the ''tail'' of the list can be taken, meaning the last ''k'' items for some ''k'', and new nodes can be added in front of it. The tail will not be duplicated, instead becoming shared between both the old list and the new list. So long as the contents of the tail are immutable, this sharing will be invisible to the program.

Many common reference-based data structures, such as [[red–black tree]]s,<ref name="sarnak2">{{cite journal |author=Neil Sarnak |author2=Robert E. Tarjan |year=1986 |title=Planar Point Location Using Persistent Search Trees |url=http://www.link.cs.cmu.edu/15859-f07/papers/point-___location.pdf |journal=Communications of the ACM |volume=29 |issue=7 |pages=669–679 |doi=10.1145/6138.6151 |s2cid=8745316 |author2-link=Robert Tarjan |access-date=2011-04-06 |archive-url=https://web.archive.org/web/20151010204956/http://www.link.cs.cmu.edu/15859-f07/papers/point-___location.pdf |archive-date=2015-10-10 |url-status=dead }}</ref> [[Stack (data structure)|stacks]],<ref name="okasaki2">{{Cite journal|author=Chris Okasaki|title=Purely Functional Data Structures (thesis)|url=https://www.cs.cmu.edu/~rwh/theses/okasaki.pdf}}</ref> and [[treap]]s,<ref>{{cite journal |last=Liljenzin |first=Olle |title=Confluently Persistent Sets and Maps|arxiv=1301.3388|bibcode=2013arXiv1301.3388L|year=2013 }}</ref> can easily be adapted to create a persistent version. Some others need slightly more effort, for example: [[Queue (data structure)|queues]], [[Double-ended queue|dequeues]], and extensions including [[min-deque]]s (which have an additional ''O''(1) operation ''min'' returning the minimal element) and [[random access deque]]s (which have an additional operation of random access with sub-linear, most often logarithmic, complexity).

Persistent data strctures which are based on immutable ("pure functional") structures should be constrasted with structures that used destructive updates (mutation) and are made persistent using the fat node or path copying techniques, described above.

There also exist persistent data structures which use destructive{{clarify|date=June 2013}} operations, making them impossible to implement efficiently in purely functional languages (like Haskell outside specialized monads like state or IO), but possible in languages like C or Java. These types of data structures can often be avoided with a different design. One primary advantage to using purely persistent data structures is that they often behave better in multi-threaded environments.

===Linked lists===

Line 149 ⟶ 152:

Notice two points: first, the original tree (<code>xs</code>) persists. Second, many common nodes are shared between the old tree and the new tree. Such persistence and sharing is difficult to manage without some form of [[Garbage collection (computer science)|garbage collection]] (GC) to automatically free up nodes which have no live references, and this is why GC is a feature commonly found in [[Functional programming|functional programming languages]].

==== Code ====

Github repo containing implementations of persistent BSTs using Fat Nodes, Copy-on-Write, and Path Copying Techniques.

To use the persistent BST implementations, simply clone the repository and follow the instructions provided in the README file.

'''Link: ''' https://github.com/DesaultierMAKK/PersistentBST

=== Persistent hash array mapped trie ===

Line 216 ⟶ 212:

==References==

{{Reflist}}

<references></references>

==External links==

* [http://wiki.edinburghhacklab.com/PersistentRedBlackTreeSet Lightweight Java implementation of Persistent Red-Black Trees]

* [https://persistent.codeplex.com/ Efficient persistent structures in C#]

* {{github|DesaultierMAKK/PersistentBST}} - GitHub repo containing implementations of persistent BSTs using Fat Nodes, Copy-on-Write, and Path Copying Techniques. To use the persistent BST implementations, simply clone the repository and follow the instructions provided in the README file.

[[Category:Data structures]]