Finite Maps (lazy interface)

This module re-exports the value lazy Data.Map.Lazy API. The Map k v type represents a finite map (sometimes called a dictionary) from keys of type k to values of type v. A Map is strict in its keys but lazy in its values. The functions in Data.Map.Strict are careful to force values before installing them in a Map. This is usually more efficient in cases where laziness is not essential. The functions in this module do not do so. When deciding if this is the correct data structure to use, consider:

• If you are using Int keys, you will get much better performance for most operations using Data.IntMap.Lazy.
• If you don't care about ordering, consider using Data.HashMap.Lazy from the unordered-containers package instead.

For a walkthrough of the most commonly used functions see the maps introduction. This module is intended to be imported qualified, to avoid name clashes with Prelude functions, e.g.

import Data.Map (Map)
import qualified Data.Map as Map

Note that the implementation is generally left-biased. Functions that take two maps as arguments and combine them, such as union and intersection, prefer the values in the first argument to those in the second.

Warning

The size of a Map must not exceed maxBound :: Int. Violation of this condition is not detected and if the size limit is exceeded, its behaviour is undefined.

Implementation

The implementation of Map is based on size balanced binary trees (or trees of bounded balance) as described by:

• Stephen Adams, "Efficient sets—a balancing act", Journal of Functional Programming 3(4):553-562, October 1993, https://doi.org/10.1017/S0956796800000885, https://groups.csail.mit.edu/mac/users/adams/BB/index.html.
• J. Nievergelt and E.M. Reingold, "Binary search trees of bounded balance", SIAM journal of computing 2(1), March 1973. https://doi.org/10.1137/0202005.
• Yoichi Hirai and Kazuhiko Yamamoto, "Balancing weight-balanced trees", Journal of Functional Programming 21(3):287-307, 2011, https://doi.org/10.1017/S0956796811000104

Bounds for union, intersection, and difference are as given by

• Guy Blelloch, Daniel Ferizovic, and Yihan Sun, "Parallel Ordered Sets Using Join", https://arxiv.org/abs/1602.02120v4.

Performance information

The time complexity is given for each operation in big-O notation, with <math> referring to the number of entries in the map. Operations like lookup, insert, and delete take <math> time. Binary set operations like union and intersection take <math> time, where <math> and <math> are the sizes of the smaller and larger input maps respectively.

Finite Int Maps (lazy interface)

This module re-exports the value lazy Data.IntMap.Lazy API. The IntMap v type represents a finite map (sometimes called a dictionary) from keys of type Int to values of type v. The functions in Data.IntMap.Strict are careful to force values before installing them in an IntMap. This is usually more efficient in cases where laziness is not essential. The functions in this module do not do so. For a walkthrough of the most commonly used functions see the maps introduction. This module is intended to be imported qualified, to avoid name clashes with Prelude functions, e.g.

import Data.IntMap.Lazy (IntMap)
import qualified Data.IntMap.Lazy as IntMap

Note that the implementation is generally left-biased. Functions that take two maps as arguments and combine them, such as union and intersection, prefer the values in the first argument to those in the second.

Implementation

The implementation is based on big-endian patricia trees. This data structure performs especially well on binary operations like union and intersection. Additionally, benchmarks show that it is also (much) faster on insertions and deletions when compared to a generic size-balanced map implementation (see Data.Map).

• Chris Okasaki and Andy Gill, "Fast Mergeable Integer Maps", Workshop on ML, September 1998, pages 77-86, https://web.archive.org/web/20150417234429/https://ittc.ku.edu/~andygill/papers/IntMap98.pdf.
• D.R. Morrison, "PATRICIA -- Practical Algorithm To Retrieve Information Coded In Alphanumeric", Journal of the ACM, 15(4), October 1968, pages 514-534, https://doi.org/10.1145/321479.321481.

Performance information

Operation comments contain the operation time complexity in big-O notation, with <math> referring to the number of entries in the map and <math> referring to the number of bits in an Int (32 or 64). Operations like lookup, insert, and delete have a worst-case complexity of <math>. This means that the operation can become linear in the number of elements with a maximum of <math> -- the number of bits in an Int (32 or 64). These peculiar asymptotics are determined by the depth of the Patricia trees:

• even for an extremely unbalanced tree, the depth cannot be larger than the number of elements <math>,
• each level of a Patricia tree determines at least one more bit shared by all subelements, so there could not be more than <math> levels.

If all <math> keys in the tree are between 0 and <math> (or, say, between <math> and <math>), the estimate can be refined to <math>. If the set of keys is sufficiently "dense", this becomes <math> or simply the familiar <math>, matching balanced binary trees. The most performant scenario for IntMap are keys from a contiguous subset, in which case the complexity is proportional to <math>, capped by <math>. The worst scenario are exponentially growing keys <math>, for which complexity grows as fast as <math> but again is capped by <math>. Binary set operations like union and intersection take <math> time, where <math> and <math> are the sizes of the smaller and larger input maps respectively.