## Fundamental Data Structure

Search:

**Fundamental Data Structures**

Introduction

**Abstract data type**

In computer science, an **abstract data type **(**ADT**) is a mathematical model for a certain class of data structures that have similar behavior; or for certain data types of one or more programming languages that have similar semantics. An abstract data type is defined indirectly, only by the operations that may be performed on it and by mathematical constraints on the effects (and possibly cost) of those operations.[1]

For example, an abstract stack data structure could be defined by three operations: push, that inserts some data item onto the structure, pop, that extracts an item from it (with the constraint that each pop always returns the most recently pushed item that has not been popped yet), and peek, that allows data on top of the structure to be examined without removal. When analyzing the efficiency of algorithms that use stacks, one may also specify that all operations take the same time no matter how many items have been pushed into the stack, and that the stack uses a constant amount of storage for each element.

Abstract data types are purely theoretical entities, used (among other things) to simplify the description of abstract algorithms, to classify and evaluate data structures, and to formally describe the type systems of programming languages. However, an ADT may be implemented by specific data types or data structures, in many ways and in many programming languages; or described in a formal specification language. ADTs are often implemented as modules: the module's interface declares procedures that correspond to the ADT operations, sometimes with comments that describe the constraints. This information hiding strategy allows the implementation of the module to be changed without disturbing the client programs.

The term **abstract data type **can also be regarded as a generalized approach of a number of algebraic structures, such as lattices, groups, and rings.[2] This can be treated as part of subject area of artificial intelligence. The notion of abstract data types is related to the concept of data abstraction, important in object-oriented programming and design by contract methodologies for software development.

**Defining an abstract data type (ADT)**

An abstract data type is defined as a mathematical model of the data objects that make up a data type as well as the functions that operate on these objects. There are no standard conventions for defining them. A broad division may be drawn between "imperative" and "functional" definition styles.

**Imperative abstract data type definitions**

In the "imperative" view, which is closer to the philosophy of imperative programming languages, an abstract data structure is conceived as an entity that is *mutable *— meaning that it may be in different *states *at different times.

Some operations may change the state of the ADT; therefore, the order in which operations are evaluated is important, and the same operation on the same entities may have different effects if executed at different times — just like the instructions of a computer, or the commands and procedures of an imperative language. To underscore this view, it is customary to say that the operations are *executed *or *applied*, rather than *evaluated*. The imperative style is often used when describing abstract algorithms. This is described by Donald E. Knuth and can be referenced from here The Art of Computer Programming.

Abstract data type 2

**Abstract variable**

Imperative ADT definitions often depend on the concept of an *abstract variable*, which may be regarded as the simplest non-trivial ADT. An abstract variable *V *is a mutable entity that admits two operations:

• store(*V*,*x*) where *x *is a *value *of unspecified nature; and

• fetch(*V*), that yields a value;with the constraint that

• fetch(*V*) always returns the value *x *used in the most recent store(*V*,*x*) operation on the same variable *V*.

As in so many programming languages, the operation store(*V*,*x*) is often written *V *← *x *(or some similar notation), and fetch(*V*) is implied whenever a variable *V *is used in a context where a value is required. Thus, for example, *V*← *V *+ 1 is commonly understood to be a shorthand for store(*V*,fetch(*V*) + 1).In this definition, it is implicitly assumed that storing a value into a variable *U *has no effect on the state of a distinct variable *V*. To make this assumption explicit, one could add the constraint that

• if *U *and *V *are distinct variables, the sequence { store(*U*,*x*); store(*V*,*y*) } is equivalent to { store(*V*,*y*);store(*U*,*x*) }.

More generally, ADT definitions often assume that any operation that changes the state of one ADT instance has no effect on the state of any other instance (including other instances of the same ADT) — unless the ADT axioms imply that the two instances are connected (aliased) in that sense. For example, when extending the definition of abstract variable to include abstract records, the operation that selects a field from a record variable *R *must yield a variable *V *that is aliased to that part of *R*. The definition of an abstract variable *V *may also restrict the stored values *x *to members of a specific set *X*, called the *range *or *type *of *V*. As in programming languages, such restrictions may simplify the description and analysis of algorithms, and improve their readability.

Note that this definition does not imply anything about the result of evaluating fetch(*V*) when *V *is *un-initialized*, that is, before performing any store operation on *V*. An algorithm that does so is usually considered invalid, because its effect is not defined. (However, there are some important algorithms whose efficiency strongly depends on the assumption that such a fetch is legal, and returns some arbitrary value in the variable's range.)

**Instance creation**

Some algorithms need to create new instances of some ADT (such as new variables, or new stacks). To describe such algorithms, one usually includes in the ADT definition a create() operation that yields an instance of the ADT, usually with axioms equivalent to

• the result of create() is distinct from any instance *S *in use by the algorithm. This axiom may be strengthened to exclude also partial aliasing with other instances. On the other hand, this axiom still allows implementations of create() to yield a previously created instance that has become inaccessible to the program.

Abstract data type 3

**Preconditions, post-conditions, and invariants**

In imperative-style definitions, the axioms are often expressed by *preconditions*, that specify when an operation may be executed; *postconditions*, that relate the states of the ADT before and after the execution of each operation; and *invariants*, that specify properties of the ADT that are *not *changed by the operations.

**Example: abstract stack (imperative)**

As another example, an imperative definition of an abstract stack could specify that the state of a stack *S *can be modified only by the operations

• push(*S*,*x*), where *x *is some *value *of unspecified nature; and

• pop(*S*), that yields a value as a result; with the constraint that

• For any value *x *and any abstract variable *V*, the sequence of operations { push(*S*,*x*); *V *← pop(*S*) } is equivalent to { *V *← *x *}; Since the assignment { *V *← *x *}, by definition, cannot change the state of *S*, this condition implies that { *V *← pop(*S*) } restores *S *to the state it had before the { push(*S*,*x*) }. From this condition and from the properties of abstract variables, it follows, for example, that the sequence { push(*S*,*x*); push(*S*,*y*); *U *← pop(*S*); push(*S*,*z*); *V *← pop(*S*); *W *← pop(*S*); } where *x*,*y*, and *z *are any values, and *U*, *V*, *W *are pairwise distinct variables, is equivalent to { *U *← *y*; *V *← *z*; *W *← *x *} Here it is implicitly assumed that operations on a stack instance do not modify the state of any other ADT instance, including other stacks; that is,

• For any values *x*,*y*, and any distinct stacks *S *and *T*, the sequence { push(*S*,*x*); push(*T*,*y*) } is equivalent to { push(*T*,*y*); push(*S*,*x*) }. A stack ADT definition usually includes also a Boolean-valued function empty(*S*) and a create() operation that returns a stack instance, with axioms equivalent to

• create() ≠ *S *for any stack *S *(a newly created stack is distinct from all previous stacks)

• empty(create()) (a newly created stack is empty)

• not empty(push(*S*,*x*)) (pushing something into a stack makes it non-empty)

**Single-instance style**

Sometimes an ADT is defined as if only one instance of it existed during the execution of the algorithm, and all operations were applied to that instance, which is not explicitly notated. For example, the abstract stack above could have been defined with operations push(*x*) and pop(), that operate on "the" only existing stack. ADT definitions in this style can be easily rewritten to admit multiple coexisting instances of the ADT, by adding an explicit instance parameter (like *S *in the previous example) to every operation that uses or modifies the implicit instance.

On the other hand, some ADTs cannot be meaningfully defined without assuming multiple instances. This is the case when a single operation takes two distinct instances of the ADT as parameters. For an example, consider augmenting the definition of the stack ADT with an operation compare(*S*,*T*) that checks whether the stacks *S *and *T *contain the same items in the same order. Abstract data type 4

**Functional ADT definitions**

Another way to define an ADT, closer to the spirit of functional programming, is to consider each state of the structure as a separate entity. In this view, any operation that modifies the ADT is modeled as a mathematical function that takes the old state as an argument, and returns the new state as part of the result. Unlike the "imperative" operations, these functions have no side effects. Therefore, the order in which they are evaluated is immaterial, and the same operation applied to the same arguments (including the same input states) will always return the same results (and output states). In the functional view, in particular, there is no way (or need) to define an "abstract variable" with the semantics of imperative variables (namely, with fetch and store operations). Instead of storing values into variables, one passes them as arguments to functions.

**Example: abstract stack (functional)**

For example, a complete functional-style definition of a stack ADT could use the three operations:

• push: takes a stack state and an arbitrary value, returns a stack state;

• top: takes a stack state, returns a value;

• pop: takes a stack state, returns a stack state; with the following axioms:

• top(push(*s*,*x*)) = *x *(pushing an item onto a stack leaves it at the top)

• pop(push(*s*,*x*)) = *s *(pop undoes the effect of push)

In a functional-style definition there is no need for a create operation. Indeed, there is no notion of "stack instance". The stack states can be thought of as being potential states of a single stack structure, and two stack states that contain the same values in the same order are considered to be identical states. This view actually mirrors the behavior of some concrete implementations, such as linked lists with hash cons. Instead of create(), a functional definition of a stack ADT may assume the existence of a special stack state, the *empty stack*, designated by a special symbol like Λ or "()"; or define a bottom() operation that takes no arguments and returns this special stack state. Note that the axioms imply that

• push(Λ,*x*) ≠ Λ

In a functional definition of a stack one does not need an empty predicate: instead, one can test whether a stack is empty by testing whether it is equal to Λ.

Note that these axioms do not define the effect of top(*s*) or pop(*s*), unless *s *is a stack state returned by a push.

Since push leaves the stack non-empty, those two operations are undefined (hence invalid) when *s *= Λ. On the other hand, the axioms (and the lack of side effects) imply that push(*s*,*x*) = push(*t*,*y*) if and only if *x *= *y *and *s *= *t*.

As in some other branches of mathematics, it is customary to assume also that the stack states are only those whose existence can be proved from the axioms in a finite number of steps. In the stack ADT example above, this rule means that every stack is a *finite *sequence of values, that becomes the empty stack (Λ) after a finite number of pops.

By themselves, the axioms above do not exclude the existence of infinite stacks (that can be poped forever, each time yielding a different state) or circular stacks (that return to the same state after a finite number of pops). In particular, they do not exclude states *s *such that pop(*s*) = *s *or push(*s*,*x*) = *s *for some *x*. However, since one cannot obtain such stack states with the given operations, they are assumed "not to exist".

Abstract data type 5

**Advantages of abstract data typing**

• Encapsulation

Abstraction provides a promise that any implementation of the ADT has certain properties and abilities; knowing these is all that is required to make use of an ADT object. The user does not need any technical knowledge of how the implementation works to use the ADT. In this way, the implementation may be complex but will be encapsulated in a simple interface when it is actually used.

• Localization of change

Code that uses an ADT object will not need to be edited if the implementation of the ADT is changed. Since any changes to the implementation must still comply with the interface, and since code using an ADT may only refer to properties and abilities specified in the interface, changes may be made to the implementation without requiring any changes in code where the ADT is used.

• Flexibility

Different implementations of an ADT, having all the same properties and abilities, are equivalent and may be used somewhat interchangeably in code that uses the ADT. This gives a great deal of flexibility when using ADT objects in different situations. For example, different implementations of an ADT may be more efficient in different situations; it is possible to use each in the situation where they are preferable, thus increasing overall efficiency.

**Typical operations**

Some operations that are often specified for ADTs (possibly under other names) are

• compare(*s*,*t*), that tests whether two structures are equivalent in some sense;

• hash(*s*), that computes some standard hash function from the instance's state;

• print(*s*) or show(*s*), that produces a human-readable representation of the structure's state. In imperative-style ADT definitions, one often finds also

• create(), that yields a new instance of the ADT;

• initialize(*s*), that prepares a newly created instance *s *for further operations, or resets it to some "initial state";

• copy(*s*,*t*), that puts instance *s *in a state equivalent to that of *t*;

• clone(*t*), that performs *s *← new(), copy(*s*,*t*), and returns *s*;

• free(*s*) or destroy(*s*), that reclaims the memory and other resources used by *s*;

The free operation is not normally relevant or meaningful, since ADTs are theoretical entities that do not "use memory". However, it may be necessary when one needs to analyze the storage used by an algorithm that uses the ADT. In that case one needs additional axioms that specify how much memory each ADT instance uses, as a function of its state, and how much of it is returned to the pool by free.

**Examples**

Some common ADTs, which have proved useful in a great variety of applications, are

• Container

• Deque

• List

• Map

• Multimap

• Multiset

• Priority queue

• Queue Abstract data type 6

• Set

• Stack

• String

• Tree

Each of these ADTs may be defined in many ways and variants, not necessarily equivalent. For example, a stack ADT may or may not have a count operation that tells how many items have been pushed and not yet popped. This choice makes a difference not only for its clients but also for the implementation.

**Implementation**

Implementing an ADT means providing one procedure or function for each abstract operation. The ADT instances are represented by some concrete data structure that is manipulated by those procedures, according to the ADT's specifications. Usually there are many ways to implement the same ADT, using several different concrete data structures. Thus, for example, an abstract stack can be implemented by a linked list or by an array. An ADT implementation is often packaged as one or more modules, whose interface contains only the signature (number and types of the parameters and results) of the operations. The implementation of the module — namely, the bodies of the procedures and the concrete data structure used — can then be hidden from most clients of the module. This makes it possible to change the implementation without affecting the clients. When implementing an ADT, each instance (in imperative-style definitions) or each state (in functional-style definitions) is usually represented by a handle of some sort.[3] Modern object-oriented languages, such as C++ and Java, support a form of abstract data types. When a class is used as a type, it is an abstract type that refers to a hidden representation. In this model an ADT is typically implemented as a class, and each instance of the ADT is an object of that class. The module's interface typically declares the constructors as ordinary procedures, and most of the other ADT operations as methods of that class. However, such an approach does not easily encapsulate multiple representational variants found in an ADT. It also can undermine the extensibility of object-oriented programs. In a pure object-oriented program that uses interfaces as types, types refer to behaviors not representations.

**Example: implementation of the stack ADT**

As an example, here is an implementation of the stack ADT above in the C programming language.

**Imperative-style interface**

An imperative-style interface might be: **typedef struct **stack_Rep stack_Rep; */* Type: instance representation (an opaque record). */*

**typedef **stack_Rep *stack_T; */* Type: handle to a stack instance (an opaque pointer). */*

**typedef **void *stack_Item; */* Type: value that can be stored in stack (arbitrary address). */*

stack_T stack_create(void); */* Create new stack instance, initially empty. */*

void stack_push(stack_T s, stack_Item e); */* Add an item at the top of the stack. */*

stack_Item stack_pop(stack_T s); */* Remove the top item from the stack and return it . */*

Abstract data type 7 int stack_empty(stack_T ts); */* Check whether stack is empty. */*

This implementation could be used in the following manner:#include <stack.h> */* Include the stack interface. */*

stack_T t = stack_create(); */* Create a stack instance. */*

int foo = 17; */* An arbitrary datum. */*

t = stack_push(t, &foo); */* Push the address of 'foo' onto the stack. */*

…void *e = stack_pop(t); */* Get the top item and delete it from the stack. */*

**if **(stack_empty(t)) { … } */* Do something if stack is empty. */ *…

This interface can be implemented in many ways. The implementation may be arbitrarily inefficient, since the formal definition of the ADT, above, does not specify how much space the stack may use, nor how long each operation should take. It also does not specify whether the stack state *t *continues to exist after a call *s *← pop(*t*).

In practice the formal definition should specify that the space is proportional to the number of items pushed and not yet popped; and that every one of the operations above must finish in a constant amount of time, independently of that number. To comply with these additional specifications, the implementation could use a linked list, or an array (with dynamic resizing) together with two integers (an item count and the array size)

**Functional-style interface**

Functional-style ADT definitions are more appropriate for functional programming languages, and vice-versa. However, one can provide a functional style interface even in an imperative language like C. For example:

**typedef struct **stack_Rep stack_Rep; */* Type: stack state representation (an opaque record). */*

**typedef **stack_Rep *stack_T; */* Type: handle to a stack state (an opaque pointer). */*

**typedef **void *stack_Item; */* Type: item (arbitrary address). */*

stack_T stack_empty(void); */* Returns the empty stack state. */*

stack_T stack_push(stack_T s, stack_Item x); */* Adds x at the top of s, returns the resulting state. */*

stack_Item stack_top(stack_T s); */* Returns the item currently at the top of s. */*

stack_T stack_pop(stack_T s); */* Remove the top item from s, returns the resulting state. */*

The main problem is that C lacks garbage collection, and this makes this style of programming impractical; moreover, memory allocation routines in C are slower than allocation in a typical garbage collector, thus the performance impact of so many allocations is even greater. Abstract data type 8

**ADT libraries**

Many modern programming languages, such as C++ and Java, come with standard libraries that implement several common ADTs, such as those listed above.

**Built-in abstract data types**

The specification of some programming languages is intentionally vague about the representation of certain built-in data types, defining only the operations that can be done on them. Therefore, those types can be viewed as "built-in ADTs". Examples are the arrays in many scripting languages, such as Awk, Lua, and Perl, which can be regarded as an implementation of the Map or Table ADT.

**References**

[1] Barbara Liskov, Programming with Abstract Data Types, in Proceedings of the ACM SIGPLAN Symposium on Very High Level Languages, pp. 50--59, 1974, Santa Monica, California

[2] Rudolf Lidl (2004). *Abstract Algebra*. Springer. ISBN 81-8128-149-7., Chapter 7,section 40.

[3] Robert Sedgewick (1998). *Algorithms in C*. Addison/Wesley. ISBN 0-201-31452-5., definition 4.4.

**Further**

• Mitchell, John C.; Plotkin, Gordon (July 1988). "Abstract Types Have Existential Type" (http:/ / theory. stanford. edu/ ~jcm/ papers/ mitch-plotkin-88. pdf). *ACM Transactions on Programming Languages and Systems ***10 **(3).

**External links**

• Abstract data type (http:/ / www. nist. gov/ dads/ HTML/ abstractDataType. html) in NIST Dictionary of Algorithms and Data Structures Data structure

**Data structure**

A hash table In computer science, a **data structure **is a particular way of storing and organizing data in a computer so that it can be used efficiently.[1][2] Different kinds of data structures are suited to different kinds of applications, and some are highly specialized to specific tasks. For example, B-trees are particularly well-suited for implementation of databases, while compiler implementations usually use hash tables to look up identifiers. Data structures provide a means to manage huge amounts of data efficiently, such as large databases and internet indexing services. Usually, efficient data structures are a key to designing efficient algorithms. Some formal design methods and programming languages emphasize data structures, rather than algorithms, as the key organizing factor in software design.

**Overview**

• An array data structure stores a number of elements of the same type in a specific order. They are accessed using an integer to specify which element is required (although the elements may be of almost any type). Arrays may be fixed-length or expandable.

• Record (also called tuple or struct) Records are among the simplest data structures. A record is a value that contains other values, typically in fixed number and sequence and typically indexed by names. The elements of records are usually called *fields *or *members*.

• A hash or dictionary or map is a more flexible variation on a record, in which name-value pairs can be added and deleted freely.

• Union. A union type definition will specify which of a number of permitted primitive types may be stored in its instances, e.g. "float or long integer". Contrast with a record, which could be defined to contain a float *and *an integer; whereas, in a union, there is only one value at a time.

• A tagged union (also called a variant, variant record, discriminated union, or disjoint union) contains an additional field indicating its current type, for enhanced type safety.

• A set is an abstract data structure that can store specific values, without any particular order, and no repeated values. Values themselves are not retrieved from sets, rather one tests a value for membership to obtain a Boolean "in" or "not in".

• An object contains a number of data fields, like a record, and also a number of program code fragments for accessing or modifying them. Data structures not containing code, like those above, are called plain old data structure.Many others are possible, but they tend to be further variations and compounds of the above.

Data structure

**Basic principles**

Data structures are generally based on the ability of a computer to fetch and store data at any place in its memory, specified by an address—a bit string that can be itself stored in memory and manipulated by the program. Thus the record and array data structures are based on computing the addresses of data items with arithmetic operations; while the linked data structures are based on storing addresses of data items within the structure itself. Many data structures use both principles, sometimes combined in non-trivial ways (as in XOR linking) The implementation of a data structure usually requires writing a set of procedures that create and manipulate instances of that structure. The efficiency of a data structure cannot be analyzed separately from those operations. This observation motivates the theoretical concept of an abstract data type, a data structure that is defined indirectly by the operations that may be performed on it, and the mathematical properties of those operations (including their space and time cost).

**Language support**

Most assembly languages and some low-level languages, such as BCPL(Basic Combined Programming Language), lack support for data structures. Many high-level programming languages, and some higher-level assembly languages, such as MASM, on the other hand, have special syntax or other built-in support for certain data structures, such as vectors (one-dimensional arrays) in the C language or multi-dimensional arrays in Pascal. Most programming languages feature some sorts of library mechanism that allows data structure implementations to be reused by different programs. Modern languages usually come with standard libraries that implement the most common data structures. Examples are the C++ Standard Template Library, the Java Collections Framework, and Microsoft's .NET Framework. Modern languages also generally support modular programming, the separation between the interface of a library module and its implementation. Some provide opaque data types that allow clients to hide implementation details. Object-oriented programming languages, such as C++, Java and .NET Framework may use classes for this purpose. Many known data structures have concurrent versions that allow multiple computing threads to access the data structure simultaneously.

**References**

[1] Paul E. Black (ed.), entry for *data structure *in *Dictionary of Algorithms and Data Structures. U.S. National Institute of Standards and** Technology. 15 December 2004. Online version *(http:/ / www. itl. nist. gov/ div897/ sqg/ dads/ HTML/ datastructur. html) *Accessed May 21,** 2009.*

[2] Entry *data structure *in the Encyclop.dia Britannica (2009) Online entry (http:/ / www. britannica. com/ EBchecked/ topic/ 152190/data-structure) accessed on May 21, 2009.

**Further reading**

• Peter Brass, *Advanced Data Structures*, Cambridge University Press, 2008.

• Donald Knuth, *The Art of Computer Programming*, vol. 1. Addison-Wesley, 3rd edition, 1997.

• Dinesh Mehta and Sartaj Sahni *Handbook of Data Structures and Applications*, Chapman and Hall/CRC Press, 2007.

• Niklaus Wirth, *Algorithms and Data Structures*, Prentice Hall, 1985. Data structure 11

**External links**

• UC Berkeley video course on data structures (http:/ / academicearth. org/ courses/ data-structures)

• Descriptions (http:/ / nist. gov/ dads/ ) from the Dictionary of Algorithms and Data Structures

• CSE.unr.edu (http:/ / www. cse. unr. edu/ ~bebis/ CS308/ )

• Data structures course with animations (http:/ / www. cs. auckland. ac. nz/ software/ AlgAnim/ ds_ToC. html)

• Data structure tutorials with animations (http:/ / courses. cs. vt. edu/ ~csonline/ DataStructures/ Lessons/ index.html)

• An Examination of Data Structures from .NET perspective (http:/ / msdn. microsoft. com/ en-us/ library/aa289148(VS. 71). aspx)

• Schaffer, C. *Data Structures and Algorithm Analysis *(http:/ / people. cs. vt. edu/ ~shaffer/ Book/ C+ +3e20110915. pdf)

**Analysis of algorithms**

In computer science, the **analysis of algorithms **is the determination of the number of resources (such as time and storage) necessary to execute them. Most algorithms are designed to work with inputs of arbitrary length. Usually the efficiency or running time of an algorithm is stated as a function relating the input length to the number of steps (time complexity) or storage locations (space complexity). Algorithm analysis is an important part of a broader computational complexity theory, which provides theoretical estimates for the resources needed by any algorithm which solves a given computational problem. These estimates provide an insight into reasonable directions of search for efficient algorithms. In theoretical analysis of algorithms it is common to estimate their complexity in the asymptotic sense, i.e., to estimate the complexity function for arbitrarily large input. Big O notation, omega notation and theta notation are used to this end. For instance, binary search is said to run in a number of steps proportional to the logarithm of the length of the list being searched, or in O(log(n)), colloquially "in logarithmic time". Usually asymptotic estimates are used because different implementations of the same algorithm may differ in efficiency. However the efficiencies of any two "reasonable" implementations of a given algorithm are related by a constant multiplicative factor called a *hidden constant*. Exact (not asymptotic) measures of efficiency can sometimes be computed but they usually require certain assumptions concerning the particular implementation of the algorithm, called model of computation. A model of computation may be defined in terms of an abstract computer, e.g., Turing machine, and/or by postulating that certain operations are executed in unit time. For example, if the sorted list to which we apply binary search has *n *elements, and we can guarantee that each lookup of an element in the list can be done in unit time, then at most log2*n *+ 1 time units are needed to return an answer.

**Cost models**

Time efficiency estimates depend on what we define to be a step. For the analysis to correspond usefully to the actual execution time, the time required to perform a step must be guaranteed to be bounded above by a constant. One must be careful here; for instance, some analyses count an addition of two numbers as one step. This assumption may not be warranted in certain contexts. For example, if the numbers involved in a computation may be arbitrarily large, the time required by a single addition can no longer be assumed to be constant. Two cost models are generally used:[1][2][3][4][5]

• the **uniform cost model**, also called **uniform-cost measurement **(and similar variations), assigns a constant cost to every machine operation, regardless of the size of the numbers involved Analysis of algorithms 12

• the **logarithmic cost model**, also called **logarithmic-cost measurement **(and variations thereof), assigns a cost to every machine operation proportional to the number of bits involved The latter is more cumbersome to use, so it's only employed when necessary, for example in the analysis of arbitrary-precision arithmetic algorithms, like those used in cryptography. A key point which is often overlooked is that published lower bounds for problems are often given for a model of computation that is more restricted than the set of operations that you could use in practice and therefore there are algorithms that are faster than what would naively be thought possible.[6]

**Run-time analysis**

Run-time analysis is a theoretical classification that estimates and anticipates the increase in *running time *(or run-time) of an algorithm as its *input size *(usually denoted as *n*) increases. Run-time efficiency is a topic of great interest in computer science: A program can take seconds, hours or even years to finish executing, depending on which algorithm it implements (see also performance analysis, which is the analysis of an algorithm's run-time in practice).

**Shortcomings of empirical metrics**

Since algorithms are platform-independent (i.e. a given algorithm can be implemented in an arbitrary programming language on an arbitrary computer running an arbitrary operating system), there are significant drawbacks to using an empirical approach to gauge the comparative performance of a given set of algorithms. Take as an example a program that looks up a specific entry in a sorted list of size *n*. Suppose this program were implemented on Computer A, a state-of-the-art machine, using a linear search algorithm, and on Computer B, a much slower machine, using a binary search algorithm. Benchmark testing on the two computers running their respective programs might look something like the following:

*n ***(list size) Computer A run-time (in nanoseconds) Computer B run-time (in nanoseconds)**

15 7 100,000

65 32 150,000

250 125 200,000

1,000 500 250,000

Based on these metrics, it would be easy to jump to the conclusion that *Computer A *is running an algorithm that is far superior in efficiency to that of *Computer B*. However, if the size of the input-list is increased to a sufficient number, that conclusion is dramatically demonstrated to be in error: Analysis of algorithms 13

*n ***(list size) Computer A run-time (in nanoseconds) Computer B run-time (in nanoseconds)**

15 7 100,000

65 32 150,000

250 125 200,000

Computer A, running the linear search program, exhibits a linear growth rate. The program's run-time is directly proportional to its input size. Doubling the input size doubles the run time, quadrupling the input size quadruples the run-time, and so forth. On the other hand, Computer B, running the binary search program, exhibits a logarithmic growth rate. Doubling the input size only increases the run time by a constant amount (in this example, 25,000 ns). Even though Computer A is ostensibly a faster machine, Computer B will inevitably surpass Computer A in run-time because it's running an algorithm with a much slower growth rate.

**Orders of growth**

Informally, an algorithm can be said to exhibit a growth rate on the order of a mathematical function if beyond a certain input size *n*, the function *f(n) *times a positive constant provides an upper bound or limit for the run-time of that algorithm. In other words, for a given input size *n *greater than some *n0 *and a constant *c*, the running time of that algorithm will never be larger than *c × f(n)*. This concept is frequently expressed using Big O notation. For example, since the run-time of insertion sort grows quadratically as its input size increases, insertion sort can be said to be of order *O(n²)*. Big O notation is a convenient way to express the worst-case scenario for a given algorithm, although it can also be used to express the average-case — for example, the worst-case scenario for quicksort is *O(n²)*, but the average-case run-time is *O(n log n)*.[7]

**Empirical orders of growth**

Assuming the execution time follows power rule, *≈ **k na*, the coefficient *a *can be found [8] by taking empirical measurements of run time at some problem-size points , and calculating so that . If the order of growth indeed follows the power rule, the empirical value of *a *will stay constant at different ranges, and if not, it will change - but still could serve for comparison of any two given algorithms as to their *empirical local orders of growth *behaviour. Applied to the above table: Analysis of algorithms 14

*n ***(list size) Computer A run-time (in nanoseconds) Local order of growth (n^_) Computer B run-time (in nanoseconds) Local order of growth (n^_)**

15 7 100,000

65 32 1.04 150,000 0.28

250 125 1.01 200,000 0.21

It is clearly seen that the first algorithm exhibits a linear order of growth indeed following the power rule. The empirical values for the second one are diminishing rapidly, suggesting it follows another rule of growth and in any case has much lower local orders of growth (and improving further still), empirically, than the first one.

**Evaluating run-time complexity**

The run-time complexity for the worst-case scenario of a given algorithm can sometimes be evaluated by examining the structure of the algorithm and making some simplifying assumptions. Consider the following pseudocode: 1 *get a positive integer from input *

2 **if **n > 10

3 **print **"This might take a while..."

4 **for **i = 1 **to **n

5 **for **j = 1 **to **i

A given computer will take a discrete amount of time to execute each of the instructions involved with carrying out this algorithm. The specific amount of time to carry out a given instruction will vary depending on which instruction is being executed and which computer is executing it, but on a conventional computer, this amount will be deterministic.[9] Say that the actions carried out in step 1 are considered to consume time T1, step 2 uses time T2, and so forth. In the algorithm above, steps 1, 2 and 7 will only be run once. For a worst-case evaluation, it should be assumed that step 3 will be run as well. Thus the total amount of time to run steps 1-3 and step 7 is: The loops in steps 4, 5 and 6 are trickier to evaluate. The outer loop test in step 4 will execute ( n + 1 ) times (note that an extra step is required to terminate the for loop, hence n + 1 and not n executions), which will consume T4( n +1 ) time. The inner loop, on the other hand, is governed by the value of i, which iterates from 1 to n. On the first pass through the outer loop, j iterates from 1 to 1: The inner loop makes one pass, so running the inner loop body (step 6) consumes T6 time, and the inner loop test (step 5) consumes 2T5 time. During the next pass through the outer loop, j iterates from 1 to 2: the inner loop makes two passes, so running the inner loop body (step 6) consumes 2T6 time, and the inner loop test (step 5) consumes 3T5 time. Altogether, the total time required to run the inner loop body can be expressed as an arithmetic progression: Analysis of algorithms 15 which can be factored[10] as The total time required to run the inner loop test can be evaluated similarly: which can be factored as Therefore the total running time for this algorithm is: which reduces to As a rule-of-thumb, one can assume that the highest-order term in any given function dominates its rate of growth and thus defines its run-time order. In this example, n² is the highest-order term, so one can conclude that f(n) = O(n²). Formally this can be proven as follows: Prove that (*for n **≥ **0*) Let k be a constant greater than or equal to [T1..T7] (*for n **≥ **1*) Therefore for A more elegant approach to analyzing this algorithm would be to declare that [T1..T7] are all equal to one unit of time greater than or equal to [T1..T7]. This would mean that the algorithm's running time breaks down as follows:[11] (*for n **≥ **1*)

**Growth rate analysis of other resources**

The methodology of run-time analysis can also be utilized for predicting other growth rates, such as consumption of memory space. As an example, consider the following pseudocode which manages and reallocates memory usage by a program based on the size of a file which that program manages: **while **(*file still open*) **let **n = *size of file ***for ***every 100,000 kilobytes of increase in file size double the amount of memory reserved *Analysis of algorithms 16

In this instance, as the file size n increases, memory will be consumed at an exponential growth rate, which is order O(2n).[12]

**Relevance**

Algorithm analysis is important in practice because the accidental or unintentional use of an inefficient algorithm can significantly impact system performance. In time-sensitive applications, an algorithm taking too long to run can render its results outdated or useless. An inefficient algorithm can also end up requiring an uneconomical amount of computing power or storage in order to run, again rendering it practically useless.

**Notes**

[1] Alfred V. Aho; John E. Hopcroft; Jeffrey D. Ullman (1974). *The design and analysis of computer algorithms*. Addison-Wesley Pub. Co.., section 1.3

[2] Juraj Hromkovič (2004). *Theoretical computer science: introduction to Automata, computability, complexity, algorithmics, randomization,** communication, and cryptography *(http:/ / books. google. com/ books?id=KpNet-n262QC& pg=PA177). Springer. pp. 177–178. ISBN 978-3-540-14015-3. .

[3] Giorgio Ausiello (1999). *Complexity and approximation: combinatorial optimization problems and their approximability properties *(http:/ /books. google. com/ books?id=Yxxw90d9AuMC& pg=PA3). Springer. pp. 3–8. ISBN 978-3-540-65431-5. .

[4] Wegener, Ingo (2005), *Complexity theory: exploring the limits of efficient algorithms *(http:/ / books. google. com/books?id=u7DZSDSUYlQC& pg=PA20), Berlin, New York: Springer-Verlag, p. 20, ISBN 978-3-540-21045-0,

[5] Robert Endre Tarjan (1983). *Data structures and network algorithms *(http:/ / books. google. com/ books?id=JiC7mIqg-X4C& pg=PA3).

SIAM. pp. 3–7. ISBN 978-0-89871-187-5. .

[6] Examples of the price of abstraction? (http:/ / cstheory. stackexchange. com/ questions/ 608/ examples-of-the-price-of-abstraction),cstheory.stack exchange.com

[7] The term *lg *is often used as shorthand for log2

[8] How To Avoid O-Abuse and Bribes (http:/ / rjlipton. wordpress. com/ 2009/ 07/ 24/ how-to-avoid-o-abuse-and-bribes/ ), at the blog "Godel’s Lost Letter and P=NP" by R. J. Lipton, professor of Computer Science at Georgia Tech, recounting idea by Robert Sedgewick

[9] However, this is not the case with a quantum computer

[10] It can be proven by induction that

[11] This approach, unlike the above approach, neglects the constant time consumed by the loop tests which terminate their respective loops, but it is trivial to prove that such omission does not affect the final result

[12] Note that this is an extremely rapid and most likely unmanageable growth rate for consumption of memory resources

**References**

• Cormen, Thomas H.; Leiserson, Charles E.; Rivest, Ronald L. & Stein, Clifford (2001). *Introduction to** Algorithms*. Chapter 1: Foundations (Second ed.). Cambridge, MA: MIT Press and McGraw-Hill. pp. 3–122. ISBN 0-262-03293-7.

**Amortized analysis**

In computer science, **amortized analysis **is a method of analyzing algorithms that considers the entire sequence of operations of the program. It allows for the establishment of a worst-case bound for the performance of an algorithm irrespective of the inputs by looking at all of the operations. At the heart of the method is the idea that while certain operations may be extremely costly in resources, they cannot occur at a high-enough frequency to weigh down the entire program because the number of less costly operations will far outnumber the costly ones in the long run, "paying back" the program over a number of iterations.[1] It is particularly useful because it guarantees worst-case performance rather than making assumptions about the state of the program.

**History**

Amortized analysis initially emerged from a method called aggregate analysis, which is now subsumed by amortized analysis. However, the technique was first formally introduced by Robert Tarjan in his paper *Amortized* *Computational Complexity*, which addressed the need for a more useful form of analysis than the common probabilistic methods used. Amortization was initially used for very specific types of algorithms, particularly those involving binary trees and union operations. However, it is now ubiquitous and comes into play when analyzing many other algorithms as well.[1]

**Method**

The method requires knowledge of which series of operations are possible. This is most commonly the case with data structures, which have state that persists between operations. The basic idea is that a worst case operation can alter the state in such a way that the worst case cannot occur again for a long time, thus "amortizing" its cost. There are generally three methods for performing amortized analysis: the aggregate method, the accounting method, and the potential method. All of these give the same answers, and their usage difference is primarily circumstantial and due to individual preference.[2]

• Aggregate analysis determines the upper bound *T*(*n*) on the total cost of a sequence of *n *operations, then calculates the average cost to be *T*(*n*) / *n*.[2]

• The accounting method determines the individual cost of each operation, combining its immediate execution time and its influence on the running time of future operations. Usually, many short-running operations accumulate a "debt" of unfavorable state in small increments, while rare long-running operations decrease it drastically.[2]

• The potential method is like the accounting method, but overcharges operations early to compensate for undercharges later.[2]

**Common use**

• In common usage, an "amortized algorithm" is one that an amortized analysis has shown to perform well.

• Online algorithms commonly use amortized analysis.

**Accounting method**

In the field of analysis of algorithms in computer science, the **accounting method **is a method of amortized analysis based on accounting. The accounting method often gives a more intuitive account of the amortized cost of an operation than either aggregate analysis or the potential method. Note, however, that this does not guarantee such analysis will be immediately obvious; often, choosing the correct parameters for the accounting method requires as much knowledge of the problem and the complexity bounds one is attempting to prove as the other two methods. The accounting method is most naturally suited for proving an O(1) bound on time. The method as explained here is for proving such a bound.

**The method**

Preliminarily, we choose a set of elementary operations which will be used in the algorithm, and arbitrarily set their cost to 1. The fact that the costs of these operations may in reality differ presents no difficulty in principle. What is important, is that each elementary operation has a constant cost. Each aggregate operation is assigned a "payment". The payment is intended to cover the cost of elementary operations needed to complete this particular operation, with some of the payment left over, placed in a pool to be used later. The difficulty with problems that require amortized analysis is that, in general, some of the operations will require greater than constant cost. This means that no constant payment will be enough to cover the worst case cost of an operation, in and of itself. With proper selection of payment, however, this is no longer a difficulty; the expensive operations will only occur when there is sufficient payment in the pool to cover their costs.

**Examples **A few examples will help to illustrate the use of the accounting method.

**Table expansion**

It is often necessary to create a table before it is known how much space is needed. One possible strategy is to double the size of the table when it is full. Here we will use the accounting method to show that the amortized cost of an insertion operation in such a table is O(1). Before looking at the procedure in detail, we need some definitions. Let T be a table, E an element to insert, num(T) the number of elements in T, and size(T) the allocated size of T. We assume the existence of operations create_table(n), which creates an empty table of size n, for now assumed to be free, and elementary_insert(T,E), which inserts element E into a table T that already has space allocated, with a cost of 1. The following pseudocode illustrates the table insertion procedure:

**function **table_insert(T,E)

**if **num(T) = size(T)

U := create_table(2 × size(T))

**for each **F **in **T

elementary_insert(U,F)

T := U elementary_insert(T,E) Without amortized analysis, the best bound we can show for n insert operations is O(n2) — this is due to the loop at line 4 that performs num(T) elementary insertions. Accounting method 19 For analysis using the accounting method, we assign a payment of 3 to each table insertion. Although the reason for this is not clear now, it will become clear during the course of the analysis. Assume that initially the table is empty with size(T) = m. The first m insertions therefore do not require reallocation and only have cost 1 (for the elementary insert). Therefore, when num(T) = m, the pool has (3 - 1).m = 2m. Inserting element m + 1 requires reallocation of the table. Creating the new table on line 3 is free (for now). The loop on line 4 requires m elementary insertions, for a cost of m. Including the insertion on the last line, the total cost for this operation is m + 1. After this operation, the pool therefore has 2m + 3 - (m + 1) = m + 2. Next, we add another m - 1 elements to the table. At this point the pool has m + 2 + 2.(m - 1) = 3m. Inserting an additional element (that is, element 2m + 1) can be seen to have cost 2m + 1 and a payment of 3. After this operation, the pool has 3m + 3 - (2m + 1) = m + 2. Note that this is the same amount as after inserting element m + 1. In fact, we can show that this will be the case for any number of reallocations. It can now be made clear why the payment for an insertion is 3. 1 goes to inserting the element the first time it is added to the table, 1 goes to moving it the next time the table is expanded, and 1 goes to moving one of the elements that was already in the table the next time the table is expanded. We initially assumed that creating a table was free. In reality, creating a table of size n may be as expensive as O(n). Let us say that the cost of creating a table of size n is n. Does this new cost present a difficulty? Not really; it turns out we use the same method to show the amortized O(1) bounds. All we have to do is change the payment. When a new table is created, there is an old table with m entries. The new table will be of size 2m. As long as the entries currently in the table have added enough to the pool to pay for creating the new table, we will be all right. We cannot expect the first entries to help pay for the new table. Those entries already paid for the current table. We must then rely on the last entries to pay the cost . This means we must add to the payment for each entry, for a total payment of 3 + 4 = 7.

**References**

• Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. *Introduction to Algorithms*, Second Edition. MIT Press and McGraw-Hill, 2001. ISBN 0-262-03293-7. Section 17.2: The accounting method, pp. 410–412. Potential method 20

**Potential method**

In computational complexity theory, the **potential method **is a method used to analyze the amortized time and space complexity of a data structure, a measure of its performance over sequences of operations that smooths out the cost of infrequent but expensive operations.[1][2]

**Definition of amortized time**

In the potential method, a function Φ is chosen that maps states of the data structure to non-negative numbers. If *S *is a state of the data structure, Φ(*S*) may be thought of intuitively as an amount of potential energy stored in that state;[1][2] alternatively, Φ(*S*) may be thought of as representing the amount of disorder in state *S *or its distance from an ideal state. The potential value prior to the operation of initializing a data structure is defined to be zero. Let *o *be any individual operation within a sequence of operations on some data structure, with *S*before denoting the state of the data structure prior to operation *o *and *S*after denoting its state after operation *o *has completed. Then, once Φ has been chosen, the amortized time for operation *o *is defined to be where *C *is a non-negative constant of proportionality (in units of time) that must remain fixed throughout the analysis. That is, the amortized time is defined to be the actual time taken by the operation plus *C *times the difference in potential caused by the operation.[1][2]

**Relation between amortized and actual time**

Despite its artificial appearance, the total amortized time of a sequence of operations provides a valid upper bound on the actual time for the same sequence of operations. That is, for any sequence of operations , the total amortized time is always at least as large as the total actual time . In more detail, where the sequence of potential function values forms a telescoping series in which all terms other than the initial and final potential function values cancel in pairs, and where the final inequality arises from the assumptions that and . Therefore, amortized time can be used to provide accurate predictions about the actual time of sequences of operations, even though the amortized time for an individual operation may vary widely from its actual time.

**Amortized analysis of worst-case inputs**

Typically, amortized analysis is used in combination with a worst case assumption about the input sequence. With this assumption, if *X *is a type of operation that may be performed by the data structure, and *n *is an integer defining the size of the given data structure (for instance, the number of items that it contains), then the amortized time for operations of type *X *is defined to be the maximum, among all possible sequences of operations on data structures of size *n *and all operations *oi *of type *X *within the sequence, of the amortized time for operation *oi*. With this definition, the time to perform a sequence of operations may be estimated by multiplying the amortized time for each type of operation in the sequence by the number of operations of that type. Potential method 21

**Example**

A dynamic array is a data structure for maintaining an array of items, allowing both random access to positions within the array and the ability to increase the array size by one. It is available in Java as the "Array List" type and in Python as the "list" type. A dynamic array may be implemented by a data structure consisting of an array *A *of items, of some length *N*, together with a number *n *≤ *N *representing the positions within the array that have been used so far. With this structure, random accesses to the dynamic array may be implemented by accessing the same cell of the internal array *A*, and when *n *< *N *an operation that increases the dynamic array size may be implemented simply by incrementing *n*. However, when *n *= *N*, it is necessary to resize *A*, and a common strategy for doing so is to double its size, replacing *A *by a new array of length 2*n*.[3] This structure may be analyzed using a potential function Φ = 2*n *− *N*. Since the resizing strategy always causes *A *to be at least half-full, this potential function is always non-negative, as desired. When an increase-size operation does not lead to a resize operation, Φ increases by 2, a constant. Therefore, the constant actual time of the operation and the constant increase in potential combine to give a constant amortized time for an operation of this type. However, when an increase-size operation causes a resize, the potential value of *n *prior to the resize decreases to zero after the resize. Allocating a new internal array *A *and copying all of the values from the old internal array to the new one takes O(*n*) actual time, but (with an appropriate choice of the constant of proportionality *C*) this is entirely cancelled by the decrease of *n *in the potential function, leaving again a constant total amortized time for the operation. The other operations of the data structure (reading and writing array cells without changing the array size) do not cause the potential function to change and have the same constant amortized time as their actual time.[2] Therefore, with this choice of resizing strategy and potential function, the potential method shows that all dynamic array operations take constant amortized time. Combining this with the inequality relating amortized time and actual time over sequences of operations, this shows that any sequence of *n *dynamic array operations takes O(*n*) actual time in the worst case, despite the fact that some of the individual operations may themselves take a linear amount of time.[2]

**Applications**

The potential function method is commonly used to analyze Fibonacci heaps, a form of priority queue in which removing an item takes logarithmic amortized time, and all other operations take constant amortized time.[4] It may also be used to analyze splay trees, a self-adjusting form of binary search tree with logarithmic amortized time per operation.[5]

**References**

1] Goodrich, Michael T.; Tamassia, Roberto (2002), "1.5.1 Amortization Techniques", *Algorithm Design: Foundations, Analysis and Internet** examples*, Wiley, pp. 36–38.

[2] Cormen, Thomas H.; Leiserson, Charles E., Rivest, Ronald L., Stein, Clifford (2001) [1990]. "17.3 The potential method". *Introduction to** Algorithms *(2nd ed.). MIT Press and McGraw-Hill. pp. 412–416. ISBN 0-262-03293-7.

[3] Goodrich and Tamassia, 1.5.2 Analyzing an Extendable Array Implementation, pp. 139–141; Cormen et al., 17.4 Dynamic tables, pp. 416–424.

[4] Cormen et al., Chapter 20, "Fibonacci Heaps", pp. 476–497.

[5] Goodrich and Tamassia, Section 3.4, "Splay Trees", pp. 185–194. 22 Sequences

**Array data type**

In computer science, an **array type **is a data type that is meant to describe a collection of *elements *(values or variables), each selected by one or more indices (identifying keys) that can be computed at run time by the program. Such a collection is usually called an **array variable**, **array value**, or simply **array**.[1] By analogy with the mathematical concepts of vector and matrix, array types with one and two indices are often called **vector type **and **matrix type**, respectively. Language support for array types may include certain built-in array data types, some syntactic constructions (*array type constructors*) that the programmer may use to define such types and declare array variables, and special notationfor indexing array elements.[1] For example, in the Pascal programming language, the declaration type My Table = array [1..4,1..2] of integer, defines a new array data type called MyTable. The declaration var A: MyTable then defines a variable A of that type, which is an aggregate of eight elements, each being an integervariable identified by two indices. In the Pascal program, those elements are denoted A[1,1], A[1,2], A[2,1],… A[4,2].[2] Special array types are often defined by the language's standard libraries.Array types are distinguished from record types mainly because they allow the element indices to be computed at runtime, as in the Pascal assignment A[I,J] := A[N-I,2*J]. Among other things, this feature allows a single iterative statement to process arbitrarily many elements of an array variable.

In more theoretical contexts, especially in type theory and in the description of abstract algorithms, the terms "array" and "array type" sometimes refer to an abstract data type (ADT) also called *abstract array *or may refer to an *associative array*, a mathematical model with the basic operations and behavior of a typical array type in most languages — basically, a collection of elements that are selected by indices computed at run-time. Depending on the language, array types may overlap (or be identified with) other data types that describe aggregates of values, such as lists and strings. Array types are often implemented by array data structures, but sometimes by other means, such as hash tables, linked lists, or search trees.

**History**

Assembly languages and low-level languages like BCPL[3] generally have no syntactic support for arrays. Because of the importance of array structures for efficient computation, the earliest high-level programming languages, including FORTRAN (1957), COBOL (1960), and Algol 60 (1960), provided support for multi-dimensional arrays.

**Abstract arrays**

An array data structure can be mathematically modeled as an abstract data structure (an *abstract array*) with two operations *get*(*A*, *I*): the data stored in the element of the array *A *whose indices are the integer tuple *I*. *set*(*A*,*I*,*V*): the array that results by setting the value of that element to *V*. These operations are required to satisfy the axioms[4] *get*(*set*(*A*,*I*, *V*), *I*) = *V** get*(*set*(*A*,*I*, *V*), *J*) = *get*(*A*, *J*) if *I *≠ *J*

Array data type 23 for any array state *A*, any value *V*, and any tuples *I*, *J *for which the operations are defined.

The first axiom means that each element behaves like a variable. The second axiom means that elements with distinct indices behave as disjoint variables, so that storing a value in one element does not affect the value of any other element. These axioms do not place any constraints on the set of valid index tuples *I*, therefore this abstract model can be used for triangular matrices and other oddly-shaped arrays.

**Implementations**

In order to effectively implement variables of such types as array structures (with indexing done by pointer arithmetic), many languages restrict the indices to integer data types (or other types that can be interpreted as integers, such as bytes and enumerated types), and require that all elements have the same data type and storage size. Most of those languages also restrict each index to a finite interval of integers, that remains fixed throughout the lifetime of the array variable. In some compiled languages, in fact, the index ranges may have to be known at compile time. On the other hand, some programming languages provide more liberal array types, that allow indexing by arbitrary values, such as floating-point numbers, strings, objects, references, etc.. Such index values cannot be restricted to an interval, much less a fixed interval. So, these languages usually allow arbitrary new elements to be created at any time. This choice precludes the implementation of array types as array data structures. That is, those languages use array-like syntax to implement a more general associative array semantics, and must therefore be implemented by a hash table or some other search data structure.

**Language support**

**Multi-dimensional arrays**

The number of indices needed to specify an element is called the *dimension*, *dimensionality*, or rank of the array type. (This nomenclature conflicts with the concept of dimension in linear algebra,[5] where it is the number of elements. Thus, an array of numbers with 5 rows and 4 columns, hence 20 elements, is said to have dimension 2 in computing contexts, but represents a matrix with dimension 4-by-5 or 20 in mathematics. Also, the computer science meaning of "rank" is similar to its meaning in tensor algebra but not to the linear algebra concept of rank of a matrix.) Many languages support only one-dimensional arrays. In those languages, a multi-dimensional array is typically represented by an Iliffe vector, a one-dimensional array of references to arrays of one dimension less. A two-dimensional array, in particular, would be implemented as a vector of pointers to its rows. Thus an element in row *i *and column *j *of an array *A *would be accessed by double indexing (*A*[*i*][*j*] in typical notation). This way of emulating multi-dimensional arrays allows the creation of *ragged *or *jagged *arrays, where each row may have a different size — or, in general, where the valid range of each index depends on the values of all preceding indices. This representation for multi-dimensional arrays is quite prevalent in C and C++ software. However, C and C++ will use a linear indexing formula for multi-dimensional arrays that are declared as such, e.g. by int A[10][20] or int A[m][n], instead of the traditional int **A.[6]:p.81 Array data type 24

**Indexing notation**

Most programming languages that support arrays support the *store *and *select *operations, and have special syntax for indexing. Early languages used parentheses, e.g. A(i,j), as in FORTRAN; others choose square brackets, e.g. A[i,j] or A[i][j], as in Algol 60 and Pascal.

**Index types**

Array data types are most often implemented as array structures: with the indices restricted to integer (or totally ordered) values, index ranges fixed at array creation time, and multilinear element addressing. This was the case in most "third generation" languages, and is still the case of most systems programming languages such as Ada, C, and C++. In some languages, however, array data types have the semantics of associative arrays, with indices of arbitrary type and dynamic element creation. This is the case in some scripting languages such as Awk and Lua, and of some array types provided by standard C++ libraries.

**Bounds checking**

Some languages (like Pascal and Modula) perform bounds checking on every access, raising an exception or aborting the program when any index is out of its valid range. Compilers may allow these checks to be turned off to trade safety for speed. Other languages (like FORTRAN and C) trust the programmer and perform no checks. Good compilers may also analyze the program to determine the range of possible values that the index may have, and this analysis may lead to bounds-checking elimination.

**Index origin**

Some languages, such as C, provide only zero-based array types, for which the minimum valid value for any index is 0. This choice is convenient for array implementation and address computations. With a language such as C, a pointer to the interior of any array can be defined that will symbolically act as a pseudo-array that accommodates negative indices. This works only because C does not check an index against bounds when used. Other languages provide only *one-based *array types, where each index starts at 1; this is the traditional convention in mathematics for matrices and mathematical sequences. A few languages, such as Pascal, support *n-based *array types, whose minimum legal indices are chosen by the programmer. The relative merits of each choice have been the subject of heated debate. Neither zero-based nor one-based indexing has any natural advantage in avoiding off-by-one or fencepost errors. See comparison of programming languages (array) for the base indices used by various languages. The 0-based/1-based debate is not limited to just programming languages. For example, the elevator button for the ground-floor of a building is labeled "0" in France and many other countries, but "1" in the USA.

**Highest index**

The relation between numbers appearing in an array declaration and the index of that array's last element also varies by language. In many languages (such as C), one should specify the number of elements contained in the array; whereas in others (such as Pascal and Visual Basic .NET) one should specify the numeric value of the index of the last element. Needless to say, this distinction is immaterial in languages where the indices start at 1.

**Array algebra**

Some programming languages (including APL, Matlab, and newer versions of Fortran) directly support array programming, where operations and functions defined for certain data types are implicitly extended to arrays of elements of those types. Thus one can write *A*+*B *to add corresponding elements of two arrays *A *and *B*. The multiplication operation may be merely distributed over corresponding elements of the operands (APL) or may be Array data type 25 interpreted as the matrix product of linear algebra (Matlab).

**String types and arrays**

Many languages provide a built-in string data type, with specialized notation ("string literals") to build values of that type. In some languages (such as C), a string is just an array of characters, or is handled in much the same way. Other languages, like Pascal, may provide vastly different operations for strings and arrays.

**Array index range queries**

Some programming languages provide operations that return the size (number of elements) of a vector, or, more generally, range of each index of an array. In C and C++ arrays do not support the *size *function, so programmers often have to declare separate variable to hold the size, and pass it to procedures as a separate parameter. Elements of a newly created array may have undefined values (as in C), or may be defined to have a specific "default" value such as 0 or a null pointer (as in Java). In C++ a std::vector object supports the *store*, *select*, and *append *operations with the performance characteristics discussed above. Vectors can be queried for their size and can be resized. Slower operations like inserting an element in the middle are also supported.

**Slicing**

An array slicing operation takes a subset of the elements of an array-typed entity (value or variable) and then assembles them as another array-typed entity, possibly with other indices. If array types are implemented as array structures, many useful slicing operations (such as selecting a sub-array, swapping indices, or reversing the direction of the indices) can be performed very efficiently by manipulating the dope vector of the structure. The possible slicings depend on the implementation details: for example, FORTRAN allows slicing off one column of a matrix variable, but not a row, and treat it as a vector; whereas C allow slicing off a row from a matrix, but not a column. On the other hand, other slicing operations are possible when array types are implemented in other ways.

**Resizing**

Some languages allow *dynamic arrays *(also called *resizable*, *growable*, or *extensible*): array variables whose index ranges may be expanded at any time after creation, without changing the values of its current elements. For one-dimensional arrays, this facility may be provided as an operation "append(*A*,*x*)" that increases the size of the array *A *by one and then sets the value of the last element to *x*. Other array types (such as Pascal strings) provide a concatenation operator, which can be used together with slicing to achieve that effect and more. In some languages, assigning a value to an element of an array automatically extends the array, if necessary, to include that element. In other array types, a slice can be replaced by an array of different size" with subsequent elements being renumbered accordingly — as in Python's list assignment "*A*[5:5] = [10,20,30]", that inserts three new elements (10,20, and 30) before element "*A*[5]". Resizable arrays are conceptually similar to lists, and the two concepts are synonymous in some languages. An extensible array can be implemented as a fixed-size array, with a counter that records how many elements are actually in use. The append operation merely increments the counter; until the whole array is used, when the append operation may be defined to fail. This is an implementation of a dynamic array with a fixed capacity, as in the string type of Pascal. Alternatively, the append operation may re-allocate the underlying array with a larger size, and copy the old elements to the new area. Array data type 26

**References**

[1] Robert W. Sebesta (2001) Concepts of Programming Languages. Addison-Wesley. 4th edition (1998), 5th edition (2001), ISBN 0-201-38596-1 ISBN13: 9780201385960

[2] K. Jensen and Niklaus Wirth, PASCAL User Manual and Report. Springer. Paperback edition (2007) 184 pages, ISBN 3-540-06950-X ISBN 978-3540069508

[3] John Mitchell, Concepts of Programming Languages. Cambridge University Press.

[4] Lukham, Suzuki (1979), "Verification of array, record, and pointer operations in Pascal". *ACM Transactions on Programming Languages and** Systems ***1(2)**, 226–244.

[5] see the definition of a matrix

[6] Brian W. Kernighan and Dennis M. Ritchie (1988), *The C programming Language*. Prentice-Hall, 205 pages.

**External links**

• NIST's Dictionary of Algorithms and Data Structures: Array (http:/ / www. nist. gov/ dads/ HTML/ array. html)

**Array data structure**

In computer science, an **array data structure **or simply an **array **is a data structure consisting of a collection of *elements *(values or variables), each identified by at least one *array index *or *key*. An array is stored so that the position of each element can be computed from its index tuple by a mathematical formula.[1][2][3] For example, an array of 10 integer variables, with indices 0 through 9, may be stored as 10 words at memory addresses 2000, 2004, 2008, … 2036, so that the element with index *i *has the address 2000 + 4 . *i*.[4] Arrays are analogous to the mathematical concepts of vectors, matrices, and tensors. Indeed, arrays with one or two indices are often called vectors or matrices, respectively. Arrays are often used to implement tables, especially lookup tables; the word *table *is sometimes used as a synonym of *array*. Arrays are among the oldest and most important data structures, and are used by almost every program. They are also used to implement many other data structures, such as lists and strings. They effectively exploit the addressing logic of computers. In most modern computers and many external storage devices, the memory is a one-dimensional array of words, whose indices are their addresses. Processors, especially vector processors, are often optimized for array operations.

Arrays are useful mostly because the element indices can be computed at run time. Among other things, this feature allows a single iterative statement to process arbitrarily many elements of an array. For that reason, the elements of an array data structure are required to have the same size and should use the same data representation. The set of valid index tuples and the addresses of the elements (and hence the element addressing formula) are usually,[3][5] but not always,[2] fixed while the array is in use.

The term *array *is often used to mean array data type, a kind of data type provided by most high-level programming languages that consists of a collection of values or variables that can be selected by one or more indices computed at run-time. Array types are often implemented by array structures; however, in some languages they may be implemented by hash tables, linked lists, search trees, or other data structures. The term is also used, especially in the description of algorithms, to mean associative array or "abstract array", a theoretical computer science model (an abstract data type or ADT) intended to capture the essential properties of arrays. Array data structure 27

**History**

The first digital computers used machine-language programming to set up and access array structures for data tables, vector and matrix computations, and for many other purposes. Von Neumann wrote the first array-sorting program (merge sort) in 1945, during the building of the first stored-program computer.[6]p. 159 Array indexing was originally done by self-modifying code, and later using index registers and indirect addressing. Some mainframes designed in the 1960s, such as the Burroughs B5000 and its successors, had special instructions for array indexing that included index-bounds checking..Assembly languages generally have no special support for arrays, other than what the machine itself provides. The earliest high-level programming languages, including FORTRAN (1957), COBOL (1960), and ALGOL 60 (1960), had support for multi-dimensional arrays, and so has C (1972). In C++ (1983), class templates exist for multi-dimensional arrays whose dimension is fixed at runtime[3][5] as well as for runtime-flexible arrays.[2]

**Applications**

Arrays are used to implement mathematical vectors and matrices, as well as other kinds of rectangular tables. Many databases, small and large, consist of (or include) one-dimensional arrays whose elements are records. Arrays are used to implement other data structures, such as heaps, hash tables, deques, queues, stacks, strings, and VLists. One or more large arrays are sometimes used to emulate in-program dynamic memory allocation, particularly memory pool allocation. Historically, this has sometimes been the only way to allocate "dynamic memory" portably. Arrays can be used to determine partial or complete control flow in programs, as a compact alternative to (otherwise repetitive), multiple IF statements. They are known in this context as control tables and are used in conjunction with a purpose built interpreter whose control flow is altered according to values contained in the array. The array may contain subroutine pointers (or relative subroutine numbers that can be acted upon by SWITCH statements) -that direct the path of the execution.

**Array element identifier and addressing formulas**

When data objects are stored in an array, individual objects are selected by an index that is usually a non-negative scalar integer. Indices are also called subscripts. An index *maps *the array value to a stored object. There are three ways in which the elements of an array can be indexed:

• **0 **(*zero-based indexing*): The first element of the array is indexed by subscript of 0.[7]

• **1 **(*one-based indexing*): The first element of the array is indexed by subscript of 1.[8]

• **n **(*n-based indexing*): The base index of an array can be freely chosen. Usually programming languages allowing

*n-based indexing *also allow negative index values and other scalar data types like enumerations, or characters may be used as an array index. Arrays can have multiple dimensions, thus it is not uncommon to access an array using multiple indices. For example a two dimensional array A with three rows and four columns might provide access to the element at the 2nd row and 4th column by the expression: A[1, 3] (in a row major language) and A[3, 1] (in a column major language) in the case of a zero-based indexing system. Thus two indices are used for a two dimensional array, three for a three dimensional array, and n for an n dimensional array. The number of indices needed to specify an element is called the dimension, dimensionality, or rank of the array. In standard arrays, each index is restricted to a certain range of consecutive integers (or consecutive values of some enumerated type), and the address of an element is computed by a "linear" formula on the indices. Array data structure 28

**One-dimensional arrays**

A one-dimensional array (or single dimension array) is a type of linear array. Accessing its elements involves a single subscript which can either represent a row or column index. As an example consider the C declaration int an Array Name[10];Syntax : datatype anArrayname[sizeofArray];

In the given example the array can contain 10 elements of any value available to the int type. In C, the array element indices are 0-9 inclusive in this case. For example, the expressions anArrayName[0], and an ArrayName[9] are the first and last elements respectively.

For a vector with linear addressing, the element with index *i *is located at the address *B *+ *c *· *i*, where *B *is a fixed *base address *and *c *a fixed constant, sometimes called the *address increment *or *stride*. If the valid element indices begin at 0, the constant *B *is simply the address of the first element of the array. For this reason, the C programming language specifies that array indices always begin at 0; and many programmers will call

that element "zeroth" rather than "first". However, one can choose the index of the first element by an appropriate choice of the base address *B*. For example,

if the array has five elements, indexed 1 through 5, and the base address *B *is replaced by *B *− 30*c*, then the indices of those same elements will be 31 to 35. If the numbering does not start at 0, the constant *B *may not be the address of any element.

**Multidimensional arrays**

For a two-dimensional array, the element with indices *i*,*j *would have address *B *+ *c *· *i *+ *d *· *j*, where the coefficients *c *and *d *are the *row *and *column address increments*, respectively.More generally, in a *k*-dimensional array, the address of an element with indices *i*1, *i*2, …, *ik *is

*B *+ *c*1 · *i*1 + *c*2 · *i*2 + … + *ck *· *ik*.

For example: int a[3][2];

This means that array a has 3 rows and 2 columns, and the array is of integer type. Here we can store 6 elements they are stored linearly but starting from first row linear then continuing with second row. The above array will be stored as a11, a12, a13, a21, a22, a23. This formula requires only *k *multiplications and *k*−1 additions, for any array that can fit in memory. Moreover, if any coefficient is a fixed power of 2, the multiplication can be replaced by bit shifting. The coefficients *ck *must be chosen so that every valid index tuple maps to the address of a distinct element. If the minimum legal value for every index is 0, then *B *is the address of the element whose indices are all zero. As in the one-dimensional case, the element indices may be changed by changing the base address *B*. Thus, if a two-dimensional array has rows and columns indexed from 1 to 10 and 1 to 20, respectively, then replacing *B *by *B *+*c*1 - − 3 *c*1 will cause them to be renumbered from 0 through 9 and 4 through 23, respectively. Taking advantage of this feature, some languages (like FORTRAN 77) specify that array indices begin at 1, as in mathematical tradition; while other languages (like Fortran 90, Pascal and Algol) let the user choose the minimum value for each index.

**Dope vectors**

The addressing formula is completely defined by the dimension *d*, the base address *B*, and the increments *c*1, *c*2, …,*ck*. It is often useful to pack these parameters into a record called the array's *descriptor *or *stride vector *or *dope vector*.[2][3] The size of each element, and the minimum and maximum values allowed for each index may also beincluded in the dope vector. The dope vector is a complete handle for the array, and is a convenient way to passarrays as arguments to procedures. Many useful array slicing operations (such as selecting a sub-array, swapping indices, or reversing the direction of the indices) can be performed very efficiently by manipulating the dope Array data structure 29 vector.[2]

**Compact layouts**

Often the coefficients are chosen so that the elements occupy a contiguous area of memory. However, that is not necessary. Even if arrays are always created with contiguous elements, some array slicing operations may create non-contiguous sub-arrays from them. There are two systematic compact layouts for a two-dimensional array. For example, consider the matrix in the row-major order layout (adopted by C for statically declared arrays), the elements in each row are stored in consecutive positions and all of the elements of a row have a lower address than any of the elements of a consecutive row:1 2 3 4 5 6 7 8 9

In column-major order (traditionally used by Fortran), the elements in each column are consecutive in memory and all of the elements of a columns have a lower address than any of the elements of a consecutive column:1 4 7 2 5 8 3 6 9

For arrays with three or more indices, "row major order" puts in consecutive positions any two elements whose index tuples differ only by one in the *last *index. "Column major order" is analogous with respect to the *first *index.

In systems which use processor cache or virtual memory, scanning an array is much faster if successive elements are stored in consecutive positions in memory, rather than sparsely scattered. Many algorithms that use multidimensional arrays will scan them in a predictable order. A programmer (or a sophisticated compiler) may use this information to choose between row- or column-major layout for each array. For example, when computing the

product *A*·*B *of two matrices, it would be best to have *A *stored in row-major order, and *B *in column-major order.

**Array resizing**

Static arrays have a size that is fixed when they are created and consequently do not allow elements to be inserted or removed. However, by allocating a new array and copying the contents of the old array to it, it is possible to effectively implement a *dynamic *version of an array; see dynamic array. If this operation is done infrequently, insertions at the end of the array require only amortized constant time. Some array data structures do not reallocate storage, but do store a count of the number of elements of the array in use, called the count or size. This effectively makes the array a dynamic array with a fixed maximum size or capacity; Pascal strings are examples of this. Array data structure 30

**Non-linear formulas**

More complicated (non-linear) formulas are occasionally used. For a compact two-dimensional triangular array, for instance, the addressing formula is a polynomial of degree 2.

**Efficiency**

Both *store *and *select *take (deterministic worst case) constant time. Arrays take linear (O(*n*)) space in the number of elements *n *that they hold. In an array with element size *k *and on a machine with a cache line size of B bytes, iterating through an array of *n *elements requires the minimum of ceiling(*nk*/B) cache misses, because its elements occupy contiguous memorylocations. This is roughly a factor of B/*k *better than the number of cache misses needed to access *n *elements atrandom memory locations. As a consequence, sequential iteration over an array is noticeably faster in practice thaniteration over many other data structures, a property called locality of reference (this does *not *mean however, thatusing a perfect hash or trivial hash within the same (local) array, will not be even faster - and achievable in constant time). Libraries provide low-level optimized facilities for copying ranges of memory (such as memcpy) which can be used to move contiguous blocks of array elements significantly faster than can be achieved through individual element access. The speedup of such optimized routines varies by array element size, architecture, and implementation.

Memory-wise, arrays are compact data structures with no per-element overhead. There may be a per-array overhead, e.g. to store index bounds, but this is language-dependent. It can also happen that elements stored in an array require *less *memory than the same elements stored in individual variables, because several array elements can be stored in a single word; such arrays are often called *packed *arrays. An extreme (but commonly used) case is the bit array, where every bit represents a single element. A single octet can thus hold up to 256 different combinations of up to 8 different conditions, in the most compact form. Array accesses with statically predictable access patterns are a major source of data parallelism.

** **

Growable arrays are similar to arrays but add the ability to insert and delete elements; adding and deleting at the end is particularly efficient. However, they reserve linear (Θ(*n*)) additional storage, whereas arrays do not reserve additional storage. Associative arrays provide a mechanism for array-like functionality without huge storage overheads when the index values are sparse. For example, an array that contains values only at indexes 1 and 2 billion may benefit from using such a structure. Specialized associative arrays with integer keys include Patricia tries, Judy arrays, and van Emde Boas trees.

Balanced trees require O(log *n*) time for indexed access, but also permit inserting or deleting elements in O(log *n*) time,[13] whereas growable arrays require linear (Θ(*n*)) time to insert or delete elements at an arbitrary position.Array data structure 31 Linked lists allow constant time removal and insertion in the middle but take linear time for indexed access. Their memory use is typically worse than arrays, but is still linear. An Iliffe vector is an alternative to a multidimensional array structure. It uses a one-dimensional array of references to arrays of one dimension less. For two dimensions, in particular, this alternative structure would be a vector of pointers to vectors, one for each row. Thus an element in row *i *and column *j *of an array *A *would be accessed by double indexing (*A*[*i*][*j*] in typical notation). This alternative structure allows *ragged *or *jagged *arrays, where each row may have a different size — or, in general, where the valid range of each index depends on the values of all preceding indices. It also saves one multiplication (by the column address increment) replacing it by a bit shift (to index the vector of row pointers) and one extra memory access (fetching the row address), which may be worthwhile in some architectures.

**Meaning of dimension**

The dimension of an array is the number of indices needed to select an element. Thus, if the array is seen as a function on a set of possible index combinations, it is the dimension of the space of which its domain is a discrete subset. Thus a one-dimensional array is a list of data, a two-dimensional array a rectangle of data, a three-dimensional array a block of data, etc. This should not be confused with the dimension of the set of all matrices with a given domain, that is, the number of elements in the array. For example, an array with 5 rows and 4 columns is two-dimensional, but such matrices form a 20-dimensional space. Similarly, a three-dimensional vector can be represented by a one-dimensional array of size three.

**Dynamic array**

Several values are inserted at the end of a dynamic array using geometric expansion. Grey cells indicate space reserved for expansion. Most insertions are fast (constant time), while some are slow due to the need for reallocation (Θ(*n*) time, labelled with turtles). The *logical size *and *capacity *of the final array are shown. In computer science, a **dynamic array**, **growable array**, **resizable array**, **dynamic table**, **mutable array**, or **array list **is a randomaccess, variable-size list data structure that allows elements to be addedor removed. It is supplied with standard libraries in many modern

mainstream programming languages. A dynamic array is not the same thing as a dynamically allocated array, which is a fixed-size array whose size is fixed when the array is allocated, although a dynamic array may use such a fixed-size array as a back end.[1]

**Bounded-size dynamic arrays and capacity **The simplest dynamic array is constructed by allocating a fixed-sizearray and then dividing it into two parts: the first stores the elements of the dynamic array and the second is reserved, or unused. We can then add or remove elements at the end of the dynamic array in constant time by using the reserved space, until this space is completely consumed. The number of elements used by the dynamic array contents is its *logical size *or *size*, while the size of the underlying array is called the dynamic array's *capacity*, which is the maximum possible size without relocating data.

In applications where the logical size is bounded, the fixed-size data structure suffices. This may be short-sighted, when problems with the array filling up turn up later. It is best to put resize code into any array, to respond to new conditions. Then choosing initial capacity is optimization, not getting the program to run. Resizing the underlying array is an expensive task, typically involving copying the entire contents of the array.

**Geometric expansion and amortized cost**

To avoid incurring the cost of resizing many times, dynamic arrays resize by a large amount, such as doubling in size, and use the reserved space for future expansion. The operation of adding an element to the end might work as follows:

As *n *elements are inserted, the capacities form a geometric progression. Expanding the array by any constant proportion ensures that inserting *n *elements takes *O*(*n*) time overall, meaning that each insertion takes amortized constant time. The value of this proportion *a *leads to a time-space tradeoff: the average time per insertion operation Dynamic array 33

is about *a*/(*a*−1), while the number of wasted cells is bounded above by (*a*−1)*n*. The choice of *a *depends on the library or application: some textbooks use *a *= 2,[2][3] but Java's ArrayList implementation uses *a *= 3/2[1] and the C implementation of Python's list data structure uses *a *= 9/8.[4] Many dynamic arrays also deallocate some of the underlying storage if its size drops below a certain threshold, such as 30% of the capacity. This threshold must be strictly smaller than 1/*a *in order to support mixed sequences of insertions and removals with amortized constant cost. Dynamic arrays are a common example when teaching amortized analysis.[2][3] Compared to linked lists, dynamic arrays have faster indexing (constant time versus linear time) and typically faster iteration due to improved locality of reference; however, dynamic arrays require linear time to insert or delete at an arbitrary location, since all following elements must be moved, while linked lists can do this in constant time. This disadvantage is mitigated by the gap buffer and *tiered vector *variants discussed under *Variants *below. Also, in a highly fragmented memory region, it may be expensive or impossible to find contiguous space for a large dynamic array, whereas linked lists do not require the whole data structure to be stored contiguously. A balanced tree can store a list while providing all operations of both dynamic arrays and linked lists reasonably efficiently, but both insertion at the end and iteration over the list are slower than for a dynamic array, in theory and in practice, due to non-contiguous storage and tree traversal/manipulation overhead. Dynamic array 34

**Variants**

Gap buffers are similar to dynamic arrays but allow efficient insertion and deletion operations clustered near the same arbitrary location. Some deque implementations use array deques, which allow amortized constant time insertion/removal at both ends, instead of just one end. Goodrich[9] presented a dynamic array algorithm called *Tiered Vectors *that provided O(n1/2) performance for order preserving insertions or deletions from the middle of the array.

Hashed Array Tree (HAT) is a dynamic array algorithm published by Sitarski in 1996.[10] Hashed Array Tree wastes order n1/2 amount of storage space, where n is the number of elements in the array. The algorithm has O(1) amortized performance when appending a series of objects to the end of a Hashed Array Tree. In a 1999 paper,[8] Brodnik et al. describe a tiered dynamic array data structure, which wastes only n1/2 space for *n *elements at any point in time, and they prove a lower bound showing that any dynamic array must waste this muchspace if the operations are to remain amortized constant time. Additionally, they present a variant where growing and shrinking the buffer has not only amortized but worst-case constant time. Bagwell (2002)[11] presented the VList algorithm, which can be adapted to implement a dynamic array.

**Language support**

C++'s std::vector is an implementation of dynamic arrays, as are the ArrayList[12] classes supplied with the Java API and the .NET Framework. The generic List<> class supplied with version 2.0 of the .NET Framework is also implemented with dynamic arrays. Smalltalk's Ordered Collection is a dynamic array with dynamic start and end-index, making the removal of the first element also O(1). Python's list datatype implementation is a dynamic array. Delphi and D implement dynamic arrays at the language's core. Ada's Ada.Containers.Vectors generic package provides dynamic array implementation for a given subtype. Many scripting languages such as Perl and Ruby offer dynamic arrays as a built-in primitive data type. Several cross-platform frameworks provide dynamic array implementations for C: CFArray and CFMutableArray in Core Foundation; GArray and GPtrArray in GLib.

**Linked list**

The principal benefit of a linked list over a conventional array is that the list elements can easily be inserted or removed without reallocation or reorganization of the entire structure because the data items need not be stored contiguously in memory or on disk. Linked lists allow insertion and removal of nodes at any point in the list, and can do so with a constant number of operations if the link previous to the link being added or removed is maintained during list traversal. On the other hand, simple linked lists by themselves do not allow random access to the data, or any form of efficient indexing. Thus, many basic operations — such as obtaining the last node of the list (assuming that the last node is not maintained as separate node reference in the list structure), or finding a node that contains a given datum, or locating the place where a new node should be inserted — may require scanning most or all of the list elements.

**History**

Linked lists were developed in 1955-56 by Allen Newell, Cliff Shaw and Herbert A. Simon at RAND Corporation as the primary data structure for their Information Processing Language. IPL was used by the authors to develop several early artificial intelligence programs, including the Logic Theory Machine, the General Problem Solver, and a computer chess program. Reports on their work appeared in IRE Transactions on Information Theory in 1956, and several conference proceedings from 1957 to 1959, including Proceedings of the Western Joint Computer Conference in 1957 and 1958, and Information Processing (Proceedings of the first UNESCO International Conference on Information Processing) in 1959. The now-classic diagram consisting of blocks representing list nodes with arrows pointing to successive list nodes appears in "Programming the Logic Theory Machine" by Newell and Shaw in Proc. WJCC, February 1957. Newell and Simon were recognized with the ACM Turing Award in 1975 Linked list 36 for having "made basic contributions to artificial intelligence, the psychology of human cognition, and list processing". The problem of machine translation for natural language processing led Victor Yngve at Massachusetts Institute of Technology (MIT) to use linked lists as data structures in his COMIT programming language for computer research in the field of linguistics. A report on this language entitled "A programming language for mechanical translation" appeared in Mechanical Translation in 1958. LISP, standing for list processor, was created by John McCarthy in 1958 while he was at MIT and in 1960 he published its design in a paper in the Communications of the ACM, entitled "Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I". One of LISP's major data structures is the linked list. By the early 1960s, the utility of both linked lists and languages which use these structures as their primary data representation was well established. Bert Green of the MIT Lincoln Laboratory published a review article entitled "Computer languages for symbol manipulation" in IRE Transactions on Human Factors in Electronics in March 1961 which summarized the advantages of the linked list approach. A later review article, "A Comparison of list-processing computer languages" by Bobrow and Raphael, appeared in Communications of the ACM in April 1964. Several operating systems developed by Technical Systems Consultants (originally of West Lafayette Indiana, and later of Chapel Hill, North Carolina) used singly linked lists as file structures. A directory entry pointed to the first sector of a file, and succeeding portions of the file were located by traversing pointers. Systems using this technique included Flex (for the Motorola 6800 CPU), mini-Flex (same CPU), and Flex9 (for the Motorola 6809 CPU). A variant developed by TSC for and marketed by Smoke Signal Broadcasting in California, used doubly linked lists in the same manner.

The TSS/360 operating system, developed by IBM for the System 360/370 machines, used a double linked list for their file system catalog. The directory structure was similar to Unix, where a directory could contain files and/or other directories and extend to any depth. A utility flea was created to fix file system problems after a crash, since modified portions of the file catalog were sometimes in memory when a crash occurred. Problems were detected by comparing the forward and backward links for consistency. If a forward link was corrupt, then if a backward link to the infected node was found, the forward link was set to the node with the backward link. A humorous comment in the source code where this utility was invoked stated "Everyone knows a flea collar gets rid of bugs in cats".

**Basic concepts and nomenclature**

Each record of a linked list is often called an **element **or **node**. The field of each node that contains the address of the next node is usually called the ** next link **or

**. The remaining fields are known as the**

*next*pointer**data**,

**information**,

**value**,

**cargo**, or

**payload**fields. The

**head**of a list is its first node. The

**tail**of a list may refer either to the rest of the list after the head, or to the last node in the list. In Lisp and some derived languages, the next node may be called the

**cdr**(pronounced

*could-er*) of the list, while the payload of the head node may be called the

**car**. Linked list 37 Bob (bottom) has the key to box 201, which contains the first half of the book and a key to box 102, which contains the rest of the book.

**Post office box analogy**

The concept of a linked list can be explained by a simple analogy to real-world post office boxes. Suppose Alice is a spy who wishes to give a codebook to Bob by putting it in a post office box and then giving him the key. However, the book is too thick to fit in a single post office box, so instead she divides the book into two halves and purchases two post office boxes. In the first box, she puts the first half of the book and a key to the second box, and in the second box she puts the second half of the book. She then gives Bob a key to the first box. No matter how large the book is, this scheme can be extended to any number of boxes by always putting the key to the next box in the previous box. In this analogy, the boxes correspond to *elements *or *nodes*, the keys correspond to *pointers*, and the book itself is the *data*. The key given to Bob is the *head *pointer, while those stored in the boxes are *next *pointers. The scheme as described above is a *singly linked list *(see below).

**Linear and circular lists**

In the last node of a list, the link field often contains a **null **reference, a special value used to indicate the lack of further nodes. A less common convention is to make it point to the first node of the list; in that case the list is said to be **circular **or **circularly linked**; otherwise it is said to be **open **or **linear**. *A circular linked list*

**Singly, doubly, and multiply linked lists**

Singly linked lists contain nodes which have a data field as well as a *next *field, which points to the next node in the linked list. *A singly linked list whose nodes contain two fields: an integer value and a link to the next node *In a **doubly linked list**, each node contains, besides the next-node link, a second link field pointing to the *previous *node in the sequence. The two links may be called **forward**(**s**) and **backwards**, or **next **and **prev**(**ious**). *A doubly linked list whose nodes contain three fields: an integer value, the link forward to the next node, and the link backward to the previous node *A technique known as XOR-linking allows a doubly linked list to be implemented using a single link field in eachnode. However, this technique requires the ability to do bit operations on addresses, and therefore may not be available in some high-level languages. Linked list 38 In a **multiply linked list**, each node contains two or more link fields, each field being used to connect the same set of data records in a different order (e.g., by name, by department, by date of birth, etc.). (While doubly linked lists can be seen as special cases of multiply linked list, the fact that the two orders are opposite to each other leads to simpler and more efficient algorithms, so they are usually treated as a separate case.) In the case of a circular doubly linked list, the only change that occurs is that end, or "tail", of the said list is linked back to the front, or "head", of the list and vice versa.

**Sentinel nodes**

In some implementations, an extra **sentinel **or **dummy **node may be added before the first data record and/or after the last one. This convention simplifies and accelerates some list-handling algorithms, by ensuring that all links can be safely dereferenced and that every list (even one that contains no data elements) always has a "first" and "last" node.

**Empty lists**

An *empty list *is a list that contains no data records. This is usually the same as saying that it has zero nodes. If sentinel nodes are being used, the list is usually said to be empty when it has only sentinel nodes.

**Hash linking**

The link fields need not be physically part of the nodes. If the data records are stored in an array and referenced by their indices, the link field may be stored in a separate array with the same indices as the data records.

**List handles**

Since a reference to the first node gives access to the whole list, that reference is often called the **address**, **pointer**, or **handle **of the list. Algorithms that manipulate linked lists usually get such handles to the input lists and return the handles to the resulting lists. In fact, in the context of such algorithms, the word "list" often means "list handle". In some situations, however, it may be convenient to refer to a list by a handle that consists of two links, pointing to its first and last nodes.

**Combining alternatives**

The alternatives listed above may be arbitrarily combined in almost every way, so one may have circular doubly linked lists without sentinels, circular singly linked lists with sentinels, etc.

**Tradeoffs**

As with most choices in computer programming and design, no method is well suited to all circumstances. A linked list data structure might work well in one case, but cause problems in another. This is a list of some of the common tradeoffs involving linked list structures.

**Linked lists vs. dynamic arrays**

A *dynamic array *is a data structure that allocates all elements contiguously in memory, and keeps a count of the current number of elements. If the space reserved for the dynamic array is exceeded, it is reallocated and (possibly) copied, an expensive operation. Linked lists have several advantages over dynamic arrays. Insertion or deletion of an element at a specific point of a list, assuming that we have a pointer to the node (before the one to be removed, or before the insertion point) already, is a constant-time operation, whereas insertion in a dynamic array at random locations will require moving half of the elements on average, and all the elements in the worst case. While one can "delete" an element from an array in constant time by somehow marking its slot as "vacant", this causes fragmentation that impedes the performance of iteration.

Moreover, arbitrarily many elements may be inserted into a linked list, limited only by the total memory available; while a dynamic array will eventually fill up its underlying array data structure and will have to reallocate — an expensive operation, one that may not even be possible if memory is fragmented, although the cost of reallocation can be averaged over insertions, and the cost of an insertion due to reallocation would still be amortized O(1). This helps with appending elements at the array's end, but inserting into (or removing from) middle positions still carries prohibitive costs due to data moving to maintain contiguity. An array from which many elements are removed may also have to be resized in order to avoid wasting too much space. On the other hand, dynamic arrays (as well as fixed-size array data structures) allow constant-time random access, while linked lists allow only sequential access to elements. Singly linked lists, in fact, can only be traversed in one direction. This makes linked lists unsuitable for applications where it's useful to look up an element by its index quickly, such as heapsort. Sequential access on arrays and dynamic arrays is also faster than on linked lists on many machines, because they have optimal locality of reference and thus make good use of data caching.

Another disadvantage of linked lists is the extra storage needed for references, which often makes them impractical for lists of small data items such as characters or boolean values, because the storage overhead for the links may exceed by a factor of two or more the size of the data. In contrast, a dynamic array requires only the space for the data itself (and a very small amount of control data).[5] It can also be slow, and with a naive allocator, wasteful, to allocate memory separately for each new element, a problem generally solved using memory pools. Some hybrid solutions try to combine the advantages of the two representations. Unrolled linked lists store several elements in each list node, increasing cache performance while decreasing memory overhead for references. CDR coding does both these as well, by replacing references with the actual data referenced, which extends off the end of the referencing record.

A good example that highlights the pros and cons of using dynamic arrays vs. linked lists is by implementing a program that resolves the Josephus problem. The Josephus problem is an election method that works by having a group of people stand in a circle. Starting at a predetermined person, you count around the circle *n *times. Once you reach the *n*th person, take them out of the circle and have the members close the circle. Then count around the circle the same *n *times and repeat the process, until only one person is left. That person wins the election. This shows the Linked list 40 strengths and weaknesses of a linked list vs. a dynamic array, because if you view the people as connected nodes in a circular linked list then it shows how easily the linked list is able to delete nodes (as it only has to rearrange the links to the different nodes). However, the linked list will be poor at finding the next person to remove and will need to search through the list until it finds that person. A dynamic array, on the other hand, will be poor at deleting nodes (or elements) as it cannot remove one node without individually shifting all the elements up the list by one.

However, it is exceptionally easy to find the *n*th person in the circle by directly referencing them by their position in the array. The list ranking problem concerns the efficient conversion of a linked list representation into an array. Although trivial for a conventional computer, solving this problem by a parallel algorithm is complicated and has been the subject of much research. A balanced tree has similar memory access patterns and space overhead to a linked list while permitting much more efficient indexing, taking O(log n) time instead of O(n) for a random access. However, insertion and deletion operations are more expensive due to the overhead of tree manipulations to maintain balance. Efficient schemes exist for trees to automatically maintain themselves in almost-balanced state, like AVL trees or red-black trees.

**Singly linked linear lists vs. other lists**

While doubly linked and/or circular lists have advantages over singly linked linear lists, linear lists offer some advantages that make them preferable in some situations. For one thing, a singly linked linear list is a recursive data structure, because it contains a pointer to a *smaller *object of the same type. For that reason, many operations on singly linked linear lists (such as merging two lists, or enumerating the elements in reverse order) often have very simple recursive algorithms, much simpler than any solution using iterative commands. While one can adapt those recursive solutions for doubly linked and circularly linked lists, the procedures generally need extra arguments and more complicated base cases.

Linear singly linked lists also allow tail-sharing, the use of a common final portion of sub-list as the terminal portion of two different lists. In particular, if a new node is added at the beginning of a list, the former list remains available as the tail of the new one — a simple example of a persistent data structure. Again, this is not true with the other variants: a node may never belong to two different circular or doubly linked lists. In particular, end-sentinel nodes can be shared among singly linked non-circular lists. One may even use the same end-sentinel node for *every *such list. In Lisp, for example, every proper list ends with a link to a special node, denoted by nil or (), whose CAR and CDR links point to itself. Thus a Lisp procedure can safely take the CAR or CDR of *any *list. Indeed, the advantages of the fancy variants are often limited to the complexity of the algorithms, not in their efficiency. A circular list, in particular, can usually be emulated by a linear list together with two variables that point to the first and last nodes, at no extra cost.

**Doubly linked vs. singly linked**

Double-linked lists require more space per node (unless one uses XOR-linking), and their elementary operations are more expensive; but they are often easier to manipulate because they allow sequential access to the list in both directions. In a doubly linked list, one can insert or delete a node in a constant number of operations given only that node's address. To do the same in a singly linked list, one must have the *address of the pointer *to that node, which is either the handle for the whole list (in case of the first node) or the link field in the *previous *node. Some algorithms require access in both directions. On the other hand, doubly linked lists do not allow tail-sharing and cannot be used as persistent data structures.

**Circularly linked vs. linearly linked**

A circularly linked list may be a natural option to represent arrays that are naturally circular, e.g. the corners of a polygon, a pool of buffers that are used and released in FIFO order, or a set of processes that should be time-shared in round-robin order. In these applications, a pointer to any node serves as a handle to the whole list. With a circular list, a pointer to the last node gives easy access also to the first node, by following one link. Thus, in applications that require access to both ends of the list (e.g., in the implementation of a queue), a circular structure allows one to handle the structure by a single pointer, instead of two.

A circular list can be split into two circular lists, in constant time, by giving the addresses of the last node of each piece. The operation consists in swapping the contents of the link fields of those two nodes. Applying the same operation to any two nodes in two distinct lists joins the two list into one. This property greatly simplifies some algorithms and data structures, such as the quad-edge and face-edge.

The simplest representation for an empty *circular *list (when such a thing makes sense) is a null pointer, indicating that the list has no nodes. Without this choice, many algorithms have to test for this special case, and handle it separately. By contrast, the use of null to denote an empty *linear *list is more natural and often creates fewer special cases.

**Using sentinel nodes**

Sentinel node may simplify certain list operations, by ensuring that the next and/or previous nodes exist for every element, and that even empty lists have at least one node. One may also use a sentinel node at the end of the list, with an appropriate data field, to eliminate some end-of-list tests. For example, when scanning the list looking for a node with a given value *x*, setting the sentinel's data field to *x *makes it unnecessary to test for end-of-list inside the loop.

Another example is the merging two sorted lists: if their sentinels have data fields set to +∞, the choice of the next output node does not need special handling for empty lists. However, sentinel nodes use up extra space (especially in applications that use many short lists), and they may complicate other operations (such as the creation of a new empty list). However, if the circular list is used merely to simulate a linear list, one may avoid some of this complexity by adding a single sentinel node to every list, between the last and the first data nodes. With this convention, an empty list consists of the sentinel node alone, pointing to itself via the next-node link. The list handle should then be a pointer to the last data node, before the sentinel, if the list is not empty; or to the sentinel itself, if the list is empty.

The same trick can be used to simplify the handling of a doubly linked linear list, by turning it into a circular doubly linked list with a single sentinel node. However, in this case, the handle should be a single pointer to the dummy node itself.[6]

**Linked list operations**

When manipulating linked lists in-place, care must be taken to not use values that you have invalidated in previous assignments. This makes algorithms for inserting or deleting linked list nodes somewhat subtle. This section gives pseudocode for adding or removing nodes from singly, doubly, and circularly linked lists in-place. Throughout we will use *null *to refer to an end-of-list marker or sentinel, which may be implemented in a number of ways.

**Linearly linked lists**

**Singly linked lists**

Our node data structure will have two fields. We also keep a variable *firstNode *which always points to the first node in the list, or is *null *for an empty list. Linked list 42

**record ***Node *{ data; *// The data being stored in the node Node *next *// A reference to the next node, null for last node*}

**record ***List *{ *Node *firstNode *// points to first node of list; null for empty list *} Traversal of a singly linked list is simple, beginning at the first node and following each *next *link until we come to the end: node := list.firstNode

**while **node not null *(do something with node.data)*

node := node.next

The following code inserts a node after an existing node in a singly linked list. The diagram shows how it works. Inserting a node before an existing one cannot be done directly; instead, one must keep track of the previous node and insert a node after it.

**function **insertAfter(*Node *node, *Node *newNode) *// insert newNode after node*

newNode.next := node.next

node.next := newNode

Inserting at the beginning of the list requires a separate function. This requires updating *firstNode*.

**function **insertBeginning(*List *list, *Node *newNode) *// insert node before current first node*

newNode.next := list.firstNode

list.firstNode := newNode

Similarly, we have functions for removing the node *after *a given node, and for removing a node from the beginning of the list. The diagram demonstrates the former. To find and remove a particular node, one must again keep track of the previous element.

Linked list 43

**function **removeAfter(*node *node) *// remove node past this one*

obsoleteNode := node.next

node.next := node.next.next destroy obsoleteNode

**function **removeBeginning(*List *list) *// remove first node*

obsoleteNode := list.firstNode

list.firstNode := list.firstNode.next *// point past deleted node*

destroy obsoleteNode

Notice that removeBeginning() sets list.firstNode to null when removing the last node in the list.

Since we can't iterate backwards, efficient insertBefore or removeBefore operations are not possible.

Appending one linked list to another can be inefficient unless a reference to the tail is kept as part of the List structure, because we must traverse the entire first list in order to find the tail, and then append the second list to this.

Thus, if two linearly linked lists are each of length , list appending has asymptotic time complexity of . In the Lisp family of languages, list appending is provided by the append procedure.

Many of the special cases of linked list operations can be eliminated by including a dummy element at the front of

the list. This ensures that there are no special cases for the beginning of the list and renders both insert Beginning() and removeBeginning() unnecessary. In this case, the first useful data in the list will be found at list.**firstNode**.next.

Linked list 44

**Circularly linked list**

In a circularly linked list, all nodes are linked in a continuous circle, without using *null. *For lists with a front and a back (such as a queue), one stores a reference to the last node in the list. The *next *node after the last node is the first node. Elements can be added to the back of the list and removed from the front in constant time.

Circularly linked lists can be either singly or doubly linked.

Both types of circularly linked lists benefit from the ability to traverse the full list beginning at any given node. This often allows us to avoid storing *firstNode *and *lastNode*, although if the list may be empty we need a special representation for the empty list, such as a *lastNode *variable which points to some node in the list or is *null *if it's empty; we use such a *lastNode *here. This representation significantly simplifies adding and removing nodes with a non-empty list, but empty lists are then a special case.

**Algorithms**

Assuming that *someNode *is some node in a non-empty circular singly linked list, this code iterates through that list starting with *someNode*:

**function **iterate(someNode)

**if **someNode ≠ **null**

node := someNode

**do**

do something with node.value node := node.next

**while **node ≠ someNode

Notice that the test "**while **node ≠ someNode" must be at the end of the loop. If the test was moved to the beginning of the loop, the procedure would fail whenever the list had only one node.

This function inserts a node "newNode" into a circular linked list after a given node "node". If "node" is null, it assumes that the list is empty.

**function **insertAfter(*Node *node, *Node *newNode)

**if **node = **null**

newNode.next := newNode

**else**

newNode.next := node.next

node.next := newNode

Suppose that "L" is a variable pointing to the last node of a circular linked list (or null if the list is empty). To append

"newNode" to the *end *of the list, one may do

insertAfter(L, newNode)

L := newNode

To insert "newNode" at the *beginning *of the list, one may do

insertAfter(L, newNode)

**if **L = **null**

L := newNode

Linked list 45

**Linked lists using arrays of nodes**

Languages that do not support any type of reference can still create links by replacing pointers with array indices.

The approach is to keep an array of records, where each record has integer fields indicating the index of the next (and possibly previous) node in the array. Not all nodes in the array need be used. If records are also not supported, parallel arrays can often be used instead.

As an example, consider the following linked list record that uses arrays instead of pointers: **record ***Entry *{

*integer *next; *// index of next entry in array*

*integer *prev; *// previous entry (if double-linked)*

*string *name;

*real *balance;

}

By creating an array of these structures, and an integer variable to store the index of the first element, a linked list can be built:

*integer *listHead

*Entry *Records[1000]

Links between elements are formed by placing the array index of the next (or previous) cell into the Next or Prev

field within a given element. For example:

**Index Next Prev Name Balance**

0 1 4 Jones, John 123.45

1 -1 0 Smith, Joseph 234.56

2 (listHead) 4 -1 Adams, Adam 0.00

3 Ignore, Ignatius 999.99

4 0 2 Another, Anita 876.54

5

6

7

In the above example, ListHead would be set to 2, the location of the first entry in the list. Notice that entry 3 and 5 through 7 are not part of the list. These cells are available for any additions to the list. By creating a ListFree integer variable, a free list could be created to keep track of what cells are available. If all entries are in use, the size

of the array would have to be increased or some elements would have to be deleted before new entries could be stored in the list.

The following code would traverse the list and display names and account balance:

i := listHead

**while **i ≥ 0 *// loop through the list*

print i, Records[i].name, Records[i].balance *// print entry*

i := Records[i].next

When faced with a choice, the advantages of this approach include:

• The linked list is relocatable, meaning it can be moved about in memory at will, and it can also be quickly and directly serialized for storage on disk or transfer over a network.

Linked list 46

• Especially for a small list, array indexes can occupy significantly less space than a full pointer on many architectures.

• Locality of reference can be improved by keeping the nodes together in memory and by periodically rearranging them, although this can also be done in a general store.

• Naive dynamic memory allocators can produce an excessive amount of overhead storage for each node allocated; almost no allocation overhead is incurred per node in this approach.

• Seizing an entry from a pre-allocated array is faster than using dynamic memory allocation for each node, since dynamic memory allocation typically requires a search for a free memory block of the desired size.

This approach has one main disadvantage, however: it creates and manages a private memory space for its nodes.

This leads to the following issues:

• It increase complexity of the implementation.

• Growing a large array when it is full may be difficult or impossible, whereas finding space for a new linked list

node in a large, general memory pool may be easier.

• Adding elements to a dynamic array will occasionally (when it is full) unexpectedly take linear (O(n)) instead of constant time (although it's still an amortized constant).

• Using a general memory pool leaves more memory for other data if the list is smaller than expected or if many nodes are freed.

For these reasons, this approach is mainly used for languages that do not support dynamic memory allocation. These disadvantages are also mitigated if the maximum size of the list is known at the time the array is created.

**Language support**

Many programming languages such as Lisp and Scheme have singly linked lists built in. In many functional languages, these lists are constructed from nodes, each called a *cons *or *cons cell*. The cons has two fields: the *car*, a reference to the data for that node, and the *cdr*, a reference to the next node. Although cons cells can be used to build other data structures, this is their primary purpose. In languages that support abstract data types or templates, linked list ADTs or templates are available for building linked lists. In other languages, linked lists are typically built using references together with records.

**Internal and external storage**

When constructing a linked list, one is faced with the choice of whether to store the data of the list directly in the linked list nodes, called *internal storage*, or merely to store a reference to the data, called *external storage*. Internal storage has the advantage of making access to the data more efficient, requiring less storage overall, having better locality of reference, and simplifying memory management for the list (its data is allocated and deallocated at the same time as the list nodes).

External storage, on the other hand, has the advantage of being more generic, in that the same data structure and machine code can be used for a linked list no matter what the size of the data is. It also makes it easy to place the same data in multiple linked lists. Although with internal storage the same data can be placed in multiple lists by including multiple *next *references in the node data structure, it would then be necessary to create separate routines to add or delete cells based on each field. It is possible to create additional linked lists of elements that use internal storage by using external storage, and having the cells of the additional linked lists store references to the nodes of the linked list containing the data.

In general, if a set of data structures needs to be included in multiple linked lists, external storage is the best approach. If a set of data structures need to be included in only one linked list, then internal storage is slightly better, unless a generic linked list package using external storage is available. Likewise, if different sets of data that can be stored in the same data structure are to be included in a single linked list, then internal storage would be fine.

Linked list 47

Another approach that can be used with some languages involves having different data structures, but all have the initial fields, including the *next *(and *prev *if double linked list) references in the same location. After defining separate structures for each type of data, a generic structure can be defined that contains the minimum amount of data shared by all the other structures and contained at the top (beginning) of the structures. Then generic routines can be created that use the minimal structure to perform linked list type operations, but separate routines can then handle the specific data. This approach is often used in message parsing routines, where several types of messages are received, but all start with the same set of fields, usually including a field for message type. The generic routines are used to add new messages to a queue when they are received, and remove them from the queue in order to process the message. The message type field is then used to call the correct routine to process the specific type of message.

**Example of internal and external storage**

Suppose you wanted to create a linked list of families and their members. Using internal storage, the structure might look like the following:

**record ***member *{ *// member of a family*

*member *next;

*string *firstName;

*integer *age;

}

**record ***family *{ *// the family itself*

*family *next;

*string *lastName;

*string *address;

*member *members *// head of list of members of this family*

}

To print a complete list of families and their members using internal storage, we could write:

aFamily := Families *// start at head of families list*

**while **aFamily ≠ **null ***// loop through list of families*

print information about family

aMember := aFamily.members *// get head of list of this family's members*

**while **aMember ≠ **null ***// loop through list of members*

print information about member

aMember := aMember.next

aFamily := aFamily.next

Using external storage, we would create the following structures:

**record ***node *{ *// generic link structure*

BLOG COMMENTS POWERED BY DISQUS