# Finger tree

In computer science, a **finger tree** is a purely functional data structure that can be used to efficiently implement other functional data structures. A finger tree gives amortized constant time access to the "fingers" (leaves) of the tree, which is where data is stored, and concatenation and splitting logarithmic time in the size of the smaller piece. It also stores in each internal node the result of applying some associative operation to its descendants. This "summary" data stored in the internal nodes can be used to provide the functionality of data structures other than trees.

## Overview

Ralph Hinze and Ross Paterson state a finger tree is a functional representation of persistent sequences that can access the ends in amortized constant time. Concatenation and splitting can be done in logarithmic time in the size of the smaller piece. The structure can also be made into a general purpose data structure by defining the split operation in a general form, then it can work as a sequence, priority queue, search tree, priority search queue and more."[1]

A *finger* is a point where you can access *part* of a data structure; in imperative languages, this is called a pointer.[2] In a finger tree, the fingers are structures that point to the ends of a sequence, or the leaf nodes. The fingers are added on to the original tree to allow for that constant time access to fingers. In the images shown below, the fingers are the lines reaching out of the spine to the nodes.

A finger tree is composed of different *layers* which can be identified by the nodes along its *spine*. The spine of a tree can be thought of the trunk in the same way trees have leaves and a root. Though finger trees are often shown with the spine and branches coming off the sides, there are actually two nodes on the spine at each level that have been paired to make this central spine. The *prefix* is on the left of the spine, while the *suffix* is on the right. Each of those nodes has a link to the next level of the spine until they reach the root.[2]

The first level of the tree contains only values, the leaf nodes of the tree, and is of depth 0. The second level is of depth 1. The third is of depth 2 and so on. The closer to the root, the deeper the subtrees of the original tree (the tree before it was a finger tree) the nodes points to. In this way, working down the tree is going from the leaves to the root of the tree, which is the opposite of the typical tree data structure. To get this nice and unusual structure, we have to make sure the original tree has a uniform depth. To ensure that the depth is uniform, when declaring the node object, it must be parameterized by the type of the child. The nodes on the spine of depth 1 and above point to trees, and with this parameterization they can be represented by the nested nodes.[3]

### Transforming a tree into a finger tree

We will start this process with a balanced 2-3 tree. For the finger tree to work, all the leaf nodes need to also be level.

A finger is “a structure providing efficient access to nodes of a tree near a distinguished location.”[1] To make a finger tree we need to put fingers to the right and left ends of the tree and transform it like a zipper. This gives us that constant amortized time access to the ends of a sequence.

To transform, start with the balanced 2-3 tree.

Take the leftmost and rightmost internal nodes of the tree and pull them up so the rest of the tree dangles between them as shown in the image to the right.

Combines the spines to make a standard 2-3 finger tree.

This can be described as:

```
data FingerTree a = Empty
| Single a
| Deep (Digit a) (FingerTree (Node a)) (Digit a)
data Node a = Node2 a a | Node3 a a a
```

The digits in the examples shown are the nodes with letters. Each list is divided by the prefix or suffix of each node on the spine. In a transformed 2-3 tree it seems that the digit lists at the top level can have a length of two or three with the lower levels only having length of one or two. In order for some application of finger trees to run so efficiently, finger trees allow between one and four subtrees on each level.

The digits of the finger tree can be transformed into a list like so:

```
type Digit a = [a]
```

And so on the image, the top level has elements of type *a*, the next has elements of type *Node a* because the node in between the spine and leaves, and this would go on meaning in general that the *n*th level of the tree has elements of type *a*, or 2-3 trees of depth n. This means a sequence of *n* elements is represented by a tree of depth Θ(log *n*). Even better, an element *d* places from the nearest end is stored at a depth of Θ(log d) in the tree.[1]

#### Reductions

Reduction of nodes:

Reduction of finger trees:

**instance** *Reduce FingerTree* **where**

*reducer* () *Empty* *z = z*

*reducer* () (*Single x*) *z = x z*

*reducer* () (*Deep pr m sf* ) *z = pr* ' (*m* '' (*sf *' ))

**where** (') = *reducer* ()

('') = *reducer* (*reducer* ())

*reducel* () *z Empty* = z

*reducel* () *z* (*Single x*) = z x

*reducel* () *z* (*Deep pr m sf* ) = ((*z* ' *pr*) '' *m*) *'sf*

**where** (' ) = *reducel* ()

('') = *reducel* (*reducel* ())[1]

## Application

Finger trees can be used to build other trees.[4] For example, a priority queue can be implemented by labeling the internal nodes by the minimum priority of its children in the tree, or an indexed list/array can be implemented with a labeling of nodes by the count of the leaves in their children. Other applications are random-access sequences, described below, ordered sequences, and interval trees.[1]

Finger trees can provide amortized O(1) pushing, reversing, popping, O(log n) append and split; and can be adapted to be indexed or ordered sequences. And like all functional data structures, it is inherently persistent; that is, older versions of the tree are always preserved.

### Random-access sequences

Finger trees can efficiently implement random-access sequences. This should support fast positional operations including accessing the *n*th element and splitting a sequence at a certain position. To do this, we annotate the finger tree with sizes.[1]

```
newtype Size = Size{ getSize :: N }
deriving (Eq, Ord)
instance Monoid Size where
∅ = Size 0
Size m ⊕ Size n = Size (m + n)
```

The *N* is for natural numbers. The new type is needed because the type is the carrier of different monoids. Another new type is still needed for the elements in the sequence, shown below.

```
newtype Elem a = Elem{ getElem :: a }
newtype Seq a = Seq (FingerTree Size (Elem a))
instance Measured (Elem a) Size where
||Elem|| = Size 1
```

These lines of code show that instance works a base case for measuring the sizes and the elements are of size one. The use of **newtype**s doesn't cause a run-time penalty in Haskell because in a library, the *Size* and *Elem* types would be hidden from the user with wrapper functions.

With these changes, the length of a sequence can now be computed in constant time.

## First publication

Finger trees were first published in 1977 by Leonidas J. Guibas,[5] and periodically refined since (e.g. a version using AVL trees,[6] non-lazy finger trees, simpler 2-3 finger trees shown here,[1] B-Trees and so on)

## Implementations

Finger trees have since been used in the Haskell core libraries (in the implementation of *Data.Sequence*), and an implementation in OCaml exists[7] which was derived from a proven-correct Coq implementation.[8] Finger trees can be implemented with or without lazy evaluation,[9] but laziness allows for simpler implementations.

## See also

## References

- Hinze, Ralf; Paterson, Ross (2006), "Finger Trees: A Simple General-purpose Data Structure" (PDF),
*Journal of Functional Programming*,**16**(2): 197–217, doi:10.1017/S0956796805005769. - Gibiansky, Andrew. "Finger Trees - Andrew Gibiansky".
*andrew.gibiansky.com*. Retrieved 2017-10-26. - "Finger Trees Done Right (I hope)".
*Good Math, Bad Math*. Retrieved 2017-10-26. - Sarkar, Abhiroop. "Finger Tree - The ultimate data structure?".
*abhiroop.github.io*. Retrieved 2017-10-26. - Guibas, L. J.; McCreight, E. M.; Plass, M. F.; Roberts, J. R. (1977), "A new representation for linear lists",
*Conference Record of the Ninth Annual ACM Symposium on Theory of Computing*, pp. 49–60. - Tsakalidis, A. K. (1985), "AVL-trees for localized search",
*Information and Control*,**67**(1–3): 173–194, doi:10.1016/S0019-9958(85)80034-6. - Caml Weekly News
- Matthieu Sozeau :: Dependent Finger Trees in Coq
- Kaplan, H.; Tarjan, R. E. (1995), "Persistent lists with catenation via recursive slow-down",
*Proceedings of the Twenty-Seventh Annual ACM Symposium on the Theory of Computing*, pp. 93–102.

## External links

- http://www.soi.city.ac.uk/~ross/papers/FingerTree.html
- http://hackage.haskell.org/packages/archive/EdisonCore/1.2.1.1/doc/html/Data-Edison-Concrete-FingerTree.html
- Example of 2-3 trees in C#
- Example of Hinze/Paterson Finger Trees in Java
- Example of Hinze/Paterson Finger Trees in C#
- "Monoids and Finger Trees in Haskell"
- "Finger tree library for Clojure"
- "Finger tree in Scalaz"
- "Verified Finger Trees in Isabelle/HOL"