James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989. 44  Home/Search   Document Not in Database   Summary   Related Articles   Check

....(i.e. the closure s environment cannot be modi ed) It is therefore likely that the adaptive mechanism could be made to work in an imperative setting as long as relevant data structures are persistent. There has been signi cant research on persistent data structures under an imperative setting [6, 5, 7]. We further note that certain benign side e ects are not harmful. For example, side e ects to objects that are not examined by the adaptive code itself are harmless. This includes print statements, or any changes to meta data structures that are somehow recording the progress of the adaptive ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-124, February 1989.

....in degree and out degree data structures partially persistent is considered. The node copying method of Driscoll et al. is extended so that updates can be performed in worst case constant time on the pointer machine model. Previously it was only known to be possible in amortised constant time [2]. The result is presented in terms of a new strategy for Dietz and Raman s dynamic two player pebble game on graphs. It is shown how to implement the strategy and the upper bound on the required number of pebbles is improved from 2b 2d O( b) to d 2b, where b is the bound of the in degree ....

....application of a partially persistent data structure is given in [4] where the planar point location problem is solved by an elegant application of partially persistent search trees. The method given in [4] can be generalised to make arbitrary bounded in degree data structures partially persistent [2]. As in [2] the data structures we consider will be described in the pointer machine model, i.e. they consist of records with a constant number of fields each containing a unit of data or a pointer to another record. The data structures can be viewed as graphs with bounded out degree. In the ....

[Article contains additional citation context not shown here]

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38:86--124, 1989.

....(i.e. the closure s environment cannot be modified) It is therefore likely that the adaptive mechanism could be made to work in an imperative setting as long as relevant data structures are persistent. There has been significant research on persistent data structures under an imperative setting [6, 5, 7]. We further note that certain benign side effects are not harmful. For example, side effects to objects that are not examined by the adaptive code itself are harmless. This includes print statements, or any changes to meta data structures that are somehow recording the progress of the ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....(i.e. the closure s environment cannot be modified) It is therefore likely that the adaptive mechanism could be made to work in an imperative setting as long as relevant data structures are persistent. There has been significant research on persistent data structures under an imperative setting [6, 5, 7]. We further note that certain benign side e#ects are not harmful. For example, side e#ects to objects that are not examined by the adaptive code itself are harmless. This includes print statements, or any changes to meta data structures that are somehow recording the progress of the adaptive ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....is dominated by the cache misses stemming from accessing the network. 4.8 Concluding remarks on algorithms Instead of using an array with primary and secondary entries we can consider the list of next events as a persistent linked list that (in the preprocessing) changes as time progresses. See [DSST86] for details on this idea. This construction gives the same asymptotic behavior. It has the additional advantage that it can easily carried over to the exploration saving idea of Section 4.6. We can see all the algorithms presented here as some clever way to ondemand create the important part of ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. In Proceedings of the Eighteenth Annual ACM Symposium on Theory of Computing, pages 109-121, 1986.

....revision of that object with those of other objects. HARMONIA s implementation of this persistent data structure is a direct descendant of that in ENSEMBLE and is also due to Tim Wagner [56, 55] the theoretical underpinnings for that design are derived from the fat node model of Driscoll et al. [18]. Building Persistent Syntax Trees The HARMONIA versioning system is built from primitive versioned data types. Each versioned data type is manifested through a low level versioned object, which is essentially a log of values stored in that object over the course of its lifetime. The primitive ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-124, February 1989. 44

....contrast, a local bottom up approach based on a functional implementation of binary counting to select the 2 nodes to split in a search tree. A weakly related bottom up approach has been presented by Brodal [1] to remove the amortization from the partial persistence technique of Driscoll et al. [5]. The structure of this paper is as follows. Section 2 describes the basic idea of the construction, Section 3 describes how to maintain ancestor pointers in a tree by using a functional stack implementation, and Section 4 describes how to achieve constant time splitting of nodes of arbitrary ....

.... can be extended to support deletions in worst case O(log n) time, matching the bounds of Harel and Lueker [8, 9] An interesting and related question to consider is if some of the presented ideas can be used to remove the amortization from the node splitting technique of Driscoll et al. [5] to make data structures fully persistent. Acknowledgments Thanks goes to Leszek Gasieniec and Arne Andersson for patient listening, and Rudolf Fleischer for comments on the manuscript. ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert Endre Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38:86--124, 1989.

....more than one incoming arc, these arcs must be labelled with the order in which they are taken by the operation at v. The nodes are numbered according to the order of evaluation. Such a graph is a datatype usage graph, or dug. Dugs are very similar to execution traces [Oka96a] and version graphs [DSST89]. During the run of an application, many different instances of an ADT will exist. For example, whilst running queue application app1 there will exist at some time an empty queue, a queue containing just True, a queue containing two copies of True, and so on. Each of these particular instances of ....

....called a version [Oka96a] A node of a dug is called a version node if it is labelled with an operation that results in a version. The subgraph of a dug containing just the version nodes is called the version graph. This is consistent with the definition of a version graph given by Driscoll et al. [DSST89]. As each operation returns only a single value, we may associate each node with the value it produces. The nodes of the version graph can be thought of as representing different versions of the ADT formed by either generating a fresh version or by mutating one or more previous versions. In the ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....hs1; e1i j hs2; e2i if both represent exactly the same term. During evaluation, the same fact may be generated with different representations. We call each representation of a fact an occurrence of the fact. Binding environments are implemented using fully persistent versions of data structures [DSST86, Die89]. When applied to bindenvs represented as arrays, a fully persistent versioning scheme permits us to carry out the following operations efficiently: 1. Create a new child version of an existing bindenv (which itself may have been created as a child version of another bindenv, and so on) The ....

James R. Driscoll, Neil Sarnak, Daniel Sleator, and Robert E. Tarjan. Making data structures persistent. In Eighteenth Annual ACM Symposium on Theory of Computing, 1986.

....on version management, for example, in software engineering, does not consider efficient use of disk pages. The paper [4] does not consider pagination and, although the structure is branched, only a current version can be split into branches. Old versions can not be modified. Driscoll et al. [2] develop techniques for making linked data structures (e.g. binary search trees) fully persistent (all versions can be read and updated) Perhaps closest to our work is that of Lanka and Mays [5] which is based on ideas from [2] Lanka and Mays fully persistent B tree maintains multiple ....

....into branches. Old versions can not be modified. Driscoll et al. 2] develop techniques for making linked data structures (e.g. binary search trees) fully persistent (all versions can be read and updated) Perhaps closest to our work is that of Lanka and Mays [5] which is based on ideas from [2]. Lanka and Mays fully persistent B tree maintains multiple versions of B trees. The Fully persistent B tree is a branched only access method. Branched only data structures can be used for branched and temporal data if the versions are made to correspond to a branch and a timestamp. Lanka ....

[Article contains additional citation context not shown here]

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38, pages 86--124, 1989.

....Data Structure There also has been much effort to make various data structures persistent such that, during a series of modifications, the old versions, as well as the newest version, of a data structure can still be accessed. Following the terminology of Driscoll, Sarnak, Sleator Tarjan [13], a data structure is partially persistent if all versions can be read but only the newest version can be updated. A data structure is fully persistent if every version can be both read and updated. 2 An array can be easily made fully persistent if it is represented as a balanced search tree. ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....which an operation is carried out can be de ned in several reasonable ways, the proper interpretation of Theorem 1 is that #ops i 2 O #upd c i 2 , i.e. the constant in front of the expression is of minor interest. Partially Persistent Binary Trees We consider partial persistence as in [4]. A study of partial persistence through pebble games has been carried out in [3] and we use a similar presentation here. We consider the following game played on a complete binary tree of height h. Each internal node has, besides pointers to its children, room for e pebbles, for some constant ....

....tree of height h. Each internal node has, besides pointers to its children, room for e pebbles, for some constant e. Updates consists of updating a leaf, and putting a pebble on the parent (this is the equivalent of copying a leaf and using an extra pointer at the parent in the node copying model [4]) Post processing consists of making sure no internal node is storing more than e pebbles. The possible operations are to remove all pebbles from a node and put one on the parent (this is the equivalent of copying an internal node, and using an extra pointer at the parent in the node copying ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-124, February 1989.

....1 . Since imperative data structures make heavy use of destructive updates, usually only the last version of a data structure is available (i.e. they are ephemeral ) Persistent data structures are useful in areas such as computational geometry, text and file editing, and tree pattern matching [DSST89, DR91], therefore being of interest for programmers in general. In the context of imperative programming, some work has been done to develop persistent data structures (e.g. DSST89, IS91] A frequently used approach to achieve persistence is to implement a data structure in a functional style (e.g. ....

....data structures are useful in areas such as computational geometry, text and file editing, and tree pattern matching [DSST89, DR91] therefore being of interest for programmers in general. In the context of imperative programming, some work has been done to develop persistent data structures (e.g. [DSST89, IS91]) A frequently used approach to achieve persistence is to implement a data structure in a functional style (e.g. Mye84, Bur82] The developments in the area of functional data structures are then of relevance for imperative programmers as well as for functional programmers. Although in a ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making Data Structures Persistent. Journal of Computer and System Sciences, 38(1):86--124, Febuary 1989.

....versions of the data structure are remembered and can be accessed. Ordinary data structures are ephemeral. Persistent data structures are used in a variety of areas, such as computational geometry, text and file editing, and high level programming languages. For references see Driscoll et al. [44]. We distinguish three types of persistent data structures, depending on how new versions of the data structure are achieved: ffl A partially persistent data structure allows all old versions to be accessed but only the most recent version to be modified. ffl A fully persistent data structure ....

....an old version of the data structure to rebuild that version from scratch. The third approach considered by Overmars is a hybrid version where in addition to the sequence of operations also every kth version of the data structure is stored (for k chosen appropriately) Later Driscoll et al. [44] developed two efficient general techniques for making a large class of pointer based data structures both partially and fully persistent. The two techniques are denoted node copying and node spitting. The techniques require that the ephemeral data structures are pointer based, i.e. the ....

[Article contains additional citation context not shown here]

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert Endre Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38:86--124, 1989.

....overhead required between threads that exploit computational effects, increasing the opportunities for parallel execution. The term persistence is used somewhat loosely in previous work and does not always imply that all three of the above features are supported. In the work of Driscoll et al. [9], they distinguish between partially persistent, which means that the data structure only supports time travel, and fully persistent, which also supports multiple futures. They describe techniques that support both partial and full persistence, but none of the techniques support parallelism. ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-- 124, February 1989.

....in contrast, a local bottom up approach based on a functional implementation of binary counting to select the nodes to split in a search tree. A weakly related bottomup approach has been presented by Brodal [1] to remove the amortization from the partial persistence technique of Driscoll et al. [5]. The structure of this paper is as follows. Section 2 describes the basic idea of the construction, Section 3 describes how to maintain ancestor pointers in a tree by using a functional stack implementation, and Section 4 describes how to achieve constant time splitting of nodes of arbitrary ....

.... can be extended to support deletions in worst case O(log n) time, matching the bounds of Harel and Lueker [8, 9] An interesting and related question to consider is if some of the presented ideas can be used to remove the amortization from the node splitting technique of Driscoll et al. [5] to make data structures fully persistent. Acknowledgments Thanks goes to Leszek G asieniec and Arne Andersson for patient listening, and Rudolf Fleischer for comments on the manuscript. ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert Endre Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38:86--124, 1989.

....time complexity, is specified in isolation. Instead, we develop ad hoc, but pragmatically useful, techniques for reasoning about the time complexity of lazy amortized data structures without regard to the contexts in which the data structures will be used. A data structure is called persistent [5] if, after an update, the old version of the data structure is still accessible. A data structure that is not persistent is called ephemeral. In functional programming terminology, an ephemeral data structure is one that must be single threaded [21] and a persistent data structure is one that may ....

....are implemented in a lazy language, then both data structures will pay these overheads. In that case, the amortized data structure should usually be faster as well as simpler. Our research is also related to earlier studies in the im67 perative community. Driscoll, Sarnak, Sleator, and Tarjan [5] described several techniques for implementing persistent imperative data structures, and Raman [18] explored techniques for eliminating amortization from imperative data structures. 7 Discussion We have shown how lazy evaluation is essential to the design of amortized functional data ....

James R. Driscoll, Neil Sarnak, Daniel D. K. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....versions have been developed for some variants of quad trees; see Section 3. Interval trees have been proposed for handling time intervals in temporal databases [KTF95] Versioning of data structures is important in temporal databases, and versioning techniques developed for main memory structures [DSST86] have been found to be useful in temporal databases [KTF95] The two dimensional index structure of [RS94] also demonstrates the importance of using data structures developed for main memory, in database systems. Furthermore, object oriented database systems make it easy to reuse code developed ....

James R. Driscoll, Neil Sarnak, Daniel Sleator, and Robert E. Tarjan. Making data structures persistent. In Eighteenth Annual ACM Symp. on Theory of Computing, 1986.

....sequences can be brought out more clearly. The conditioning probability partition sequence is incremental in the sense that we can build a partition sequence conditioned on hOE 1 ; OE k 1 i based on a partition sequence conditioned on hOE 1 ; OE k i. It is also persistent [ Driscoll et al. 1989 ] since we can retrieve Pr( j OE 1 ; OE k ) from a partition sequence conditioned on hOE 1 ; OE k ; OE k 1 ; i. Now we turn to thresholding. Definition 19 A possible world partition sequence P = hhW 0 ; Wn i; m; fi is a threshold probability partition sequence for ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38:86--124, 1989.

....size of the search tree in that interval. We discuss when and how this can be reduced to O(log n (v 2 Gamma v 1 ) by maintaining one extra pointer with a version number in each node. 1 Introduction When balanced binary search trees are made partially persistent using the nodecopying method [5], updating remains efficient and the possibility of searching efficiently for information in the past is added to the system. In fact, the operations of updating the present version and searching in the present as well as in the past are asymptotically as efficient as in the corresponding normal ....

....keys by applying a sequence of single rotations. We do not know of any scheme which does not conform to this requirement, except the ones which apply some form of global rebuilding as in [2, 6] Partial Persistence We now make the search tree partially persistent using the node copying method [5]. A partially persistent structure is described as a structure which supports multiple versions, in such a way that all versions can be accessed, but only the newest version can be modified. As usual, we assume that versions are numbered using consecutive integers starting from one, and the ....

[Article contains additional citation context not shown here]

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making Data Structures Persistent. Journal of Computer and System Sciences, 38:86--124, 1989.

....a node do not change the node s identity. In this way POL differs from value based Prolog and relational databases, and more closely resembles so called objectoriented databases. POL supports multiple versions of the term space called worlds, and uses an algorithm devised by Driscol et al. [5] that supports efficient checkpointing of the entire term space. POL has operations to save the current term space as a world, and to reset its state to any previously saved world. A checkpoint operation does not copy the entire term space, but only an amount of data proportional to the changes ....

J. R. Driscol, N. Sarnak, D. D. Sleator and Targan, Making Data Structures Persistent, Journal of Computer and System Sciences 38, 1 (Feb. 1989), 86-124. Adams and Solomon CAPITL Page 24

....original image. The above drawback leads one to another approach, which is to design efficient algorithms to make aggregates fully persistent (i.e. purely functional) such that, after a sequence of updates, the newest version as well as all previous versions of the aggregate are still accessible [1, 5, 6, 8, 9, 10, 11, 15, 19, 22]. The challenge is to reduce as much as possible the associated overhead when maintaining multiple versions of an aggregate. In this paper, we develop a randomization technique for the efficient implementation of multiple functional arrays. The expected performance of the randomized implementation ....

....effect on garbage collectors, and its applications to other functional aggregates. Section 7 concludes this paper. 2 Functional Arrays by Fragmented Shallow Binding General techniques for making aggregate data structures fully persistent are described by Driscoll, Sarnak, Sleator, and Tarjan [10]. However, these techniques only apply to linked data structures. They cannot be applied to the usual representation of an array, which is not implemented as a linked data structure but as a successive block of locations in the random access memory (RAM) In this paper, we will use the term cache ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....a functional data structure, we expect that both the old and new versions of the data structure will be available for further processing. A data structure that supports multiple versions is called persistent, while a data structure that allows only a single version at a time is called ephemeral [7]. Functional programming languages have the curious property that all data structures are automatically persistent. Imperative data structures are typically ephemeral, but when a persistent data structure is required, imperative programmers are not surprised if the persistent data structure is ....

James R. Driscoll, Neil Sarnak, Daniel D. K. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....memoization [14] Both of these ideas have a long history in data structure design, although not always in combination. For instance, delaying the execution of potentially expensive computations (often deletions) is used to good effect in hash tables [23] priority queues [20, 7] and search trees [4]. Memoization, on the other hand, is the basic principle of such techniques as dynamic programming [1] and path compression [10, 22] In addition to delaying expensive computations, lazy evaluation provides a convenient framework for partitioning expensive computations into more manageable ....

....stages provided it can be proven that the balance will be non negative by the end of the sequence. 4 Persistence A persistent data structure is one that supports updates and queries to any previous version of the data structure, not just the most recent. Driscoll, Sarnak, Sleator, and Tarjan [4] describe several general techniques for making ordinary linked data structures persistent. However, these techniques do not apply when operations such as catenation can combine multiple versions of a data structure. In purely functional programming, where side effects are disallowed, all data ....

[Article contains additional citation context not shown here]

James R. Driscoll, Neil Sarnak, Daniel D. K. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....and the performance results are compared to those of deterministic selection strategies. 1 Introduction How to design and implement efficient aggregate data structures has been a major concern for both the designers and users of functional programming languages [1] 2] 3] 5] 6] 7] [11] [14] 17] 18] 20] 23] 25] 26] The problem becomes more complicated if access patterns to aggregates are highly variant, or even unpredictable. A common situation is where there are several representations of an aggregate, with one representation more efficient than the others for certain ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-- 124, February 1989.

....need O(1) rotations, each of which requires O(k) time. Our technique applied on BB[ trees involves O(1) rotations per operation, so that each rotation can be implemented in O(1) time. As a byproduct of the fact that rotations take O(1) time with our technique, we can obtain a persistent version [9] of our k dimensional dictionaries which requires only O(1) additional space per update. The only requirement is that the underlying data structure can be updated in O(1) time instead of O(k) for example, by using the data structure in [19] or in [12] By contrast, the algorithms in [31] use ....

....keys in linked data structures. Let S be a set of ordered keys where each comparison between two keys has outcome in [ and takes constant time. We assume the comparison model for S: thus we cannot hash keys of S nor we can access part of their bits. Following Driscoll et al. [9], we say that a linked data structure DS storing the keys in set S is a labeled directed graph whose vertices have constant outdegree. DS is a nite collection of nodes, each of which is able to hold a xed number of elds. Each eld is either an information eld (storing a key from S, a bit, an ....

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences 38 (1989), 86-124.

....only O(1) time. The vast majority of research on functional arrays has focused on detecting or enforcing single threadedness through such techniques as static analysis [7, 26, 30] linear types [36] or monads [29] An array that supports non singled threaded access is called fully persistent [14]. A number of data structures have been proposed to represent fully persistent arrays. One technique, known as version arrays [1] or shallow binding [4, 5] maintains a cache of elements along with trees of differential nodes indicating differences from the cache. This technique yields O(1) ....

....and then searching downward in the normal fashion. Lookups and updates require O(log i) time, and adding or removing a leaf in the leftmost position can be accomplished in O(1) time. Finger search trees can be made fully persistent using the (internally destructive) techniques of Driscoll et al. [14], but it is not clear whether they can be implemented purely functionally without suffering a degradation in performance. Kaplan and Tarjan [20] recently introduced the algorithmic notion of recursive slowdown, and used it to design a new purely functional implementation of constanttime ....

James R. Driscoll, Neil Sarnak, Daniel D. K. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989.

....a node do not change the node s identity. In this way POL differs from value based Prolog and relational databases, and more closely resembles so called objectoriented databases. POL supports multiple versions of the term space called worlds, and uses an algorithm devised by Driscol et al. [16] that supports efficient checkpointing of the entire term space. POL has operations to save the current term space as a world, and to reset its state to any previously saved world. A checkpoint operation does not copy the entire term space, but only an amount of data proportional to the changes ....

James R. Driscol, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-- 124, February 1989.

No context found.

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86--124, February 1989. 44

No context found.

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-124, February 1989.

No context found.

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-124, February 1989.

No context found.

James R. Driscoll, Neil Sarnak, Daniel Dominic Sleator, and Robert Endre Tarjan. Making data structures persistent. In ACM Symposium on Theory of Computing, pages 109--121, 1986.

No context found.

James R. Driscoll, Neil Sarnak, Daniel D. Sleator, and Robert E. Tarjan. Making data structures persistent. Journal of Computer and System Sciences, 38(1):86-124, February 1989.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC