pomaps: Maps and sets of partial orders

This is a package candidate release! Here you can preview how this package release will appear once published to the main package index (which can be accomplished via the 'maintain' link below). Please note that once a package has been published to the main package index it cannot be undone! Please consult the package uploading documentation for more information.


Maps (and sets) indexed by keys satisfying PartialOrd.

The goal is to provide asymptotically better data structures than simple association lists or lookup tables. Asymptotics depend on the partial order used as keys, its width \(w\) specifically (the size of the biggest anti-chain).

For partial orders with great width, this package won't provide any benefit over using association lists, so benchmark for your use-case!

[Skip to ReadMe]


Change logCHANGELOG.md
Dependenciesbase (>= && <4.11), containers (>= && <=, deepseq (>=1.1 && <1.5), ghc-prim (>=0.4 && <0.6), lattices (>=1.7 && <2) [details]
MaintainerSebastian Graf
CategoryData Structures
Home pagehttps://github.com/sgraf812/pomaps#readme
Bug trackerhttps://github.com/sgraf812/pomaps/issues
Source repositoryhead: git clone https://github.com/sgraf812/pomaps
UploadedFri Nov 17 17:06:47 UTC 2017 by sgraf812





Depend on the lattices package for the PartialOrd class.


Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info


Maintainers' corner

For package maintainers and hackage trustees

Readme for pomaps-

[back to package description]

pomaps Build Status

Reasonably fast maps (and possibly sets) based on keys satisfying PartialOrd.

This package tries to load off as much work as possible to the excellent containers library, in order to achieve acceptable performance. The interface is kept as similar to Data.Map.{Strict/Lazy} as possible, which is an excuse for somewhat lacking documentation.

POMaps basically store a decomposition of totally ordered chains (e.g. something Maps can handle). Functionality and strictness properties should be pretty much covered by the testsuite. But it's not battle-tested yet, so if you encounter space leaks in the implementation, let me know.

A rather naive implementation leads to O(w*n*log n) lookups, where w is the width of the decomposition (which should be the size of the biggest anti-chain). This is enough for me at the moment to get things going, but there is room for improvement (Sorting and Selection in Posets). Let me know if things are too slow and I'll see what I can do!