20

From my limited knowledge of Haskell, it seems that Maps (from Data.Map) are supposed to be used much like a dictionary or hashtable in other languages, and yet are implemented as self-balancing binary search trees.

Why is this? Using a binary tree reduces lookup time to O(log(n)) as opposed to O(1) and requires that the elements be in Ord. Certainly there is a good reason, so what are the advantages of using a binary tree?

Also:

In what applications would a binary tree be much worse than a hashtable? What about the other way around? Are there many cases in which one would be vastly preferable to the other? Is there a traditional hashtable in Haskell?

reem
  • 7,186
  • 4
  • 20
  • 30
  • 1
    FYI, while traditional hash tables have the problems described in the answers, there are persistent data structures that are similar in spirit and offer similar time complexity: Hash array mapped tries, used in Clojure among others. –  Sep 20 '13 at 13:20
  • "as opposed to O(1)" Only in the average case. Hash table lookup is O(n) in the worst case. – newacct Sep 20 '13 at 21:09
  • Only in hashtables implemented without open addressing. The worst case (that would cause an O(n) lookup time) is so exceedingly unlikely in open addressing that it is barely worth considering. – reem Sep 21 '13 at 00:14
  • @newacct For cuckoo hashing, lookup is worst-case O(1) time. –  Sep 21 '13 at 09:41
  • @delnan: sure, for that, insertion has bad worst-case time. – newacct Sep 21 '13 at 09:48
  • @newacct Yes, but for many application that's all one needs. Likewise, when insertion performance is more important, chaining gives worst-case O(1) time. My point is that you're ignoring the zoo of different hash table variants that cover practically any set of bounds one might want. I also already pointed you at dynamic perfect hashing. I have no idea how well it works in practice, but the asymptotic complexity is great: worst-case O(1) lookup, insert and delete (amortized for the latter two, but so are tons of great bounds including the predecessor and successor operation in a BST). –  Sep 21 '13 at 09:50

4 Answers4

29

Hash tables can't be implemented efficiently without mutable state, because they're based on array lookup. The key is hashed and the hash determines the index into an array of buckets. Without mutable state, inserting elements into the hashtable becomes O(n) because the entire array must be copied (alternative non-copying implementations, like DiffArray, introduce a significant performance penalty). Binary-tree implementations can share most of their structure so only a couple pointers need to be copied on inserts.

Haskell certainly can support traditional hash tables, provided that the updates are in a suitable monad. The hashtables package is probably the most widely used implementation.

One advantage of binary trees and other non-mutating structures is that they're persistent: it's possible to keep older copies of data around with no extra book-keeping. This might be useful in some sort of transaction algorithm for example. They're also automatically thread-safe (although updates won't be visible in other threads).

John L
  • 27,937
  • 4
  • 73
  • 88
  • Clojure hash-map seems to be a persistent hash table-ish data structure. Of course, Haskell may predate the invention (or at least widespread acceptance) of this data structure. It appears this thing is called "Hash array mapped trie". –  Sep 20 '13 at 13:20
  • There are hash array mapped trie data structures which are purely functional available for Haskell, specifically `Data.HashMap.Lazy`, `Data.HashMap.Strict`, and `Data.HashSet`, which are in `unordered-containers`. – Travis Bemann Sep 20 '13 at 19:32
  • @delnan: A "hash array-mapped trie" is not a hashtable, as that structure is commonly understood. A hash array-mapped trie is much closer to `Data.IntMap` (from `containers`) using the hash as the key. – John L Sep 23 '13 at 02:15
  • @JohnL I understand that. That's why I said "-ish". The implementation is as different as an associative container using hashes can be, but it's still the closest in interface and complexity. –  Sep 23 '13 at 09:33
  • This is probably one of the major reasons that I would like linear types. – Molly Stewart-Gallus Jun 28 '17 at 21:41
11

Traditional hashtables rely on memory mutation in their implementation. Mutable memory and referential transparency are at ends, so that relegates hashtable implementations to either the IO or ST monads. Trees can be implemented persistently and efficiently by leaving old leaves in memory and returning new root nodes which point to the updated trees. This lets us have pure Maps.

The quintessential reference is Chris Okasaki's Purely Functional Data Structures.

J. Abrahamson
  • 72,246
  • 9
  • 135
  • 180
7

Why is this? Using a binary tree reduces lookup time to O(log(n)) as opposed to O(1)

Lookup is only one of the operations; insertion/modification may be more important in many cases; there are also memory considerations. The main reason the tree representation was chosen is probably that it is more suited for a pure functional language. As "Real World Haskell" puts it:

Maps give us the same capabilities as hash tables do in other languages. Internally, a map is implemented as a balanced binary tree. Compared to a hash table, this is a much more efficient representation in a language with immutable data. This is the most visible example of how deeply pure functional programming affects how we write code: we choose data structures and algorithms that we can express cleanly and that perform efficiently, but our choices for specific tasks are often different their counterparts in imperative languages.

This:

and requires that the elements be in Ord.

does not seem like a big disadvantage. After all, with a hash map you need keys to be Hashable, which seems to be more restrictive.

In what applications would a binary tree be much worse than a hashtable? What about the other way around? Are there many cases in which one would be vastly preferable to the other? Is there a traditional hashtable in Haskell?

Unfortunately, I cannot provide an extensive comparative analysis, but there is a hash map package, and you can check out its implementation details and performance figures in this blog post and decide for yourself.

fjarri
  • 9,546
  • 39
  • 49
  • These reasons seem pretty weak. Trees aren't superior to hash tables in memory use or insertion performance, neither in general nor in this specific case. And I doubt hashablility is more restrictive than orderability - in most cases, you just combine hashes of the members instead of chaining comparisions of the members. –  Sep 20 '13 at 13:14
  • "Trees aren't superior to hash tables in memory use or insertion performance" — the point of RWH is that they are, when implemented in a pure functional language. "And I doubt hashablility is more restrictive than orderability" — ``Ord`` is derived automatically by the compiler, it can't get any easier. – fjarri Sep 20 '13 at 13:24
  • RE performance: In a purely functional implementation, yes, but only because that implementation is stupid. If the point of your first paragraph is that insertion has to copy the underlying array, then just *say that*. RE easy: It doesn't have to be *easier* than `Ord`, it just has to be *as easy*. While `deriving Hash` doesn't work today, it can easily be added, in the same manner as Ord and Eq are derived: member-wise. You don't even have to think about how to combine the member's hashes, you can just re-use another implementation (e.g. the one for Python tuples). –  Sep 20 '13 at 13:28
  • "That implementation is necessarily stupidly slow" — a link on some figures would be nice. The one I have in my answer doesn't look too bad (and it's 2 years old, so who knows what happened after that). Also don't forget about the memory footprint. As for the ``Ord``, it *already is* derived automatically, and pretty much every standard type and its uncle have it; and you admit yourself that ``Hashable`` isn't even standardized. – fjarri Sep 20 '13 at 13:38
  • RE performance: I'm talking about what John L also describes: A purely functional hash table has to copy the whole, so modification is linear time. The data structure you refer to is *not* purely functional, it uses mutable state. RE memory footprint: Are you saying hash tables take more space than trees? A BST needs at least two extra words per entry (child pointers), a hash table can get as low as 0 words (open addressing, 100% load factor), but commonly takes between one and two words (depending on the load factor and whether the hash value is cached). –  Sep 20 '13 at 13:57
  • As for Ord: I am not saying hashability is easier today. I am saying that it's equally general *in principle*, in other words, any headstart of `Ord` (that it's standardized, widely used, can be derived, etc.) is only because Ord has other common uses (e.g. sorting) and because of history (bias towards order-based maps). –  Sep 20 '13 at 14:00
  • @delnan: "Trees aren't superior to hash tables in memory use or insertion performance" Self-balancing binary search trees are superior to hash tables in worst-case performance, for insertion, lookup, whatever. – newacct Sep 20 '13 at 21:10
  • @newacct (1) The average and expected cases are usually more interesting in practice, and the constant factors are usually better. (2) Quite a few hash table schemes offer worst-case (in some cases amortized) constant time for some (cuckoo hashing) or even all (dynamic perfect hashing) of these operations. –  Sep 20 '13 at 22:29
  • Ord is actually a big semantic pain in my ass. I find myself needing to *impose* a total order on structures that don't have a canonical total order, just to stick it in a data structure. This makes the Ord type-class less than useless as documentation of a type's properties. A hashable instance is much less intrusive. – nomen May 10 '14 at 19:10
0

My answer to what the advantage of using binary trees is, would be: range queries. They require, semantically, a total preorder, and profit from a balanced search tree organization algorithmically. For simple lookup, I'm afraid there may only be good Haskell-specific answers, but not good answers per se: Lookup (and indeed hashing) requires only a setoid (equality/equivalence on its key type), which supports efficient hashing on pointers (which, for good reasons, are not ordered in Haskell). Like various forms of tries (e.g. ternary tries for elementwise update, others for bulk updates) hashing into arrays (open or closed) is typically considerably more efficient than elementwise searching in binary trees, both space and timewise. Hashing and Tries can be defined generically, though that has to be done by hand -- GHC doesn't derive it (yet?). Data structures such as Data.Map tend to be fine for prototyping and for code outside of hotspots, but where they are hot they easily become a performance bottleneck. Luckily, Haskell programmers need not be concerned about performance, only their managers. (For some reason I presently can't find a way to access the key redeeming feature of search trees amongst the 80+ Data.Map functions: a range query interface. Am I looking the wrong place?)

Fritz Henglein
  • 1