Results 1 
6 of
6
Optimal Purely Functional Priority Queues
 JOURNAL OF FUNCTIONAL PROGRAMMING
, 1996
"... Brodal recently introduced the first implementation of imperative priority queues to support findMin, insert, and meld in O(1) worstcase time, and deleteMin in O(log n) worstcase time. These bounds are asymptotically optimal among all comparisonbased priority queues. In this paper, we adapt B ..."
Abstract

Cited by 18 (1 self)
 Add to MetaCart
(Show Context)
Brodal recently introduced the first implementation of imperative priority queues to support findMin, insert, and meld in O(1) worstcase time, and deleteMin in O(log n) worstcase time. These bounds are asymptotically optimal among all comparisonbased priority queues. In this paper, we adapt Brodal's data structure to a purely functional setting. In doing so, we both simplify the data structure and clarify its relationship to the binomial queues of Vuillemin, which support all four operations in O(log n) time. Specifically, we derive our implementation from binomial queues in three steps: first, we reduce the running time of insert to O(1) by eliminating the possibility of cascading links; second, we reduce the running time of findMin to O(1) by adding a global root to hold the minimum element; and finally, we reduce the running time of meld to O(1) by allowing priority queues to contain other priority queues. Each of these steps is expressed using MLstyle functors. The last transformation, known as datastructural bootstrapping, is an interesting application of higherorder functors and recursive structures.
Purely Functional RandomAccess Lists
 In Functional Programming Languages and Computer Architecture
, 1995
"... We present a new data structure, called a randomaccess list, that supports array lookup and update operations in O(log n) time, while simultaneously providing O(1) time list operations (cons, head, tail). A closer analysis of the array operations improves the bound to O(minfi; log ng) in the wor ..."
Abstract

Cited by 18 (2 self)
 Add to MetaCart
(Show Context)
We present a new data structure, called a randomaccess list, that supports array lookup and update operations in O(log n) time, while simultaneously providing O(1) time list operations (cons, head, tail). A closer analysis of the array operations improves the bound to O(minfi; log ng) in the worst case and O(log i) in the expected case, where i is the index of the desired element. Empirical evidence suggests that this data structure should be quite efficient in practice. 1 Introduction Lists are the primary data structure in every functional programmer 's toolbox. They are simple, convenient, and usually quite efficient. The main drawback of lists is that accessing the ith element requires O(i) time. In such situations, functional programmers often find themselves longing for the efficient random access of arrays. Unfortunately, arrays can be quite awkward to implement in a functional setting, where previous versions of the array must be available even after an update. Since arra...
Purely Functional, RealTime Deques with Catenation
 Journal of the ACM
, 1999
"... We describe an efficient, purely functional implementation of deques with catenation. In addition to being an intriguing problem in its own right, finding a purely functional implementation of catenable deques is required to add certain sophisticated programming constructs to functional programming ..."
Abstract

Cited by 15 (2 self)
 Add to MetaCart
(Show Context)
We describe an efficient, purely functional implementation of deques with catenation. In addition to being an intriguing problem in its own right, finding a purely functional implementation of catenable deques is required to add certain sophisticated programming constructs to functional programming languages. Our solution has a worstcase running time of O(1) for each push, pop, inject, eject and catenation. The best previously known solution has an O(log k) time bound for the k deque operation. Our solution is not only faster but simpler. A key idea used in our result is an algorithmic technique related to the redundant digital representations used to avoid carry propagation in binary counting.
The Role of Lazy Evaluation in Amortized Data Structures
 In Proc. of the International Conference on Functional Programming
, 1996
"... Traditional techniques for designing and analyzing amortized data structures in an imperative setting are of limited use in a functional setting because they apply only to singlethreaded data structures, yet functional data structures can be nonsinglethreaded. In earlier work, we showed how lazy e ..."
Abstract

Cited by 14 (2 self)
 Add to MetaCart
(Show Context)
Traditional techniques for designing and analyzing amortized data structures in an imperative setting are of limited use in a functional setting because they apply only to singlethreaded data structures, yet functional data structures can be nonsinglethreaded. In earlier work, we showed how lazy evaluation supports functional amortized data structures and described a technique (the banker's method) for analyzing such data structures. In this paper, we present a new analysis technique (the physicist's method) and show how one can sometimes derive a worstcase data structure from an amortized data structure by appropriately scheduling the premature execution of delayed components. We use these techniques to develop new implementations of FIFO queues and binomial queues. 1 Introduction Functional programmers have long debated the relative merits of strict versus lazy evaluation. Although lazy evaluation has many benefits [11], strict evaluation is clearly superior in at least one area:...
The Role of Lazy Evaluation in Amortized Data Structures
"... 1 Introduction Functional programmers have long debated the relative merits of strict versus lazy evaluation. Although lazy evaluation has many benefits [11], strict evaluation is clearly superior in at least one area: ease of reasoning about asymptotic complexity. Because of the unpredictable natur ..."
Abstract
 Add to MetaCart
(Show Context)
1 Introduction Functional programmers have long debated the relative merits of strict versus lazy evaluation. Although lazy evaluation has many benefits [11], strict evaluation is clearly superior in at least one area: ease of reasoning about asymptotic complexity. Because of the unpredictable nature of lazy evaluation, it is notoriously difficult to reason about the complexity of algorithms in such a language. However, there are some algorithms based on lazy evaluation that cannot be programmed in (pure) strict languages without an increase in asymptotic complexity. We explore one class of such algorithms amortized data structures and describe techniques for reasoning about their complexity.
Sequence Implementations in Haskell
, 1997
"... An abstract data type sequence is defined with the operations empty, isEmpty, cons, snoc, popFront, popRear, lenghtSeq, toList, and toSeq. A sequence with the operations lookupSeq and updateSeq is an Indexable Sequence. A sequence with catenation is called a Catenable Sequence. Some functional imp ..."
Abstract
 Add to MetaCart
An abstract data type sequence is defined with the operations empty, isEmpty, cons, snoc, popFront, popRear, lenghtSeq, toList, and toSeq. A sequence with the operations lookupSeq and updateSeq is an Indexable Sequence. A sequence with catenation is called a Catenable Sequence. Some functional implementations of these abstract data types taken from the literature are described. These implementations are classified as stacks, deques, flexible arrays, and catenable lists, if they can be used as efficient implementations for each of these traditional data types. Some of them are extended to provide the operations defined for sequences. Some comments and directions for further research are also included. The implementations are made in the functional programming language Haskell as instances of one or more of the classes Sequence, IndSeq, and CatSeq, with the operations defined for each type. These instances are classified by the subset of these operations that each instance supports eff...