On Wed, Dec 16, 2009 at 2:42 PM, Richard Kelsall <span dir="ltr">&lt;<a href="mailto:r.kelsall@millstream.com">r.kelsall@millstream.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Brad Larsen wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have considered using Data.IntMap to implement a sort of faux hash<br>
table, e.g., introduce a Hashable class, and then use an IntMap to<br>
lists of Hashable.  The result would be a pure, persistent ``hash<br>
table&#39;&#39;.  In such a case, however, lookup/insert/delete operations<br>
would have average complexity logarithmic in the number of buckets.<br>
<br>
</blockquote>
<br></div>
I&#39;ll throw in an idea that has been nagging me about hash tables.<br>
You could have a list of hash tables of increasing size. On an insert<br>
collision in a smaller table all the entries get put into the next one<br>
up. For a lookup you would have to check all the tables until you find<br>
the hash.<br>
<br>
e.g.<br>
<br>
With three hash table in the list of these example sizes.<br>
Table size 2^2 = 2 probable entries before collision.<br>
           2^4 = 4<br>
           2^6 = 8<br>
<br>
h..h<br>
...h.....h.h...h<br>
h......h.......h....h...........h......h.h..........h...........<br>
<br>
<br>
I expect if it&#39;s any good it has already been done.<br><font color="#888888">
<br></font></blockquote><div><br>Your asymptotics will take a hit if the height of the tower is logarithmic in the array size, and you&#39;ll take a constant hit for bounded-height towers. <br><br>Consider that if you have density such that the biggest array has an expected population, then your smaller arrays will be relatively drastically over populated, so you&#39;ll bump up to the next largest array in more cases, paying extra seeks against disproportionally heavily loaded buckets, whereas the time could have been more gainfully employed seeking against the more uniformly distributed larger bucket.<br>
 <br>If you have a decent hash function, you won&#39;t have lumps in your distribution, so having lumps in your bucket densities is purely a pessimization. Especially when you&#39;ve ensured that those buckets that are going to be overpopulated are exactly the ones you are checking first.<br>
<br>You might consider looking at Witold Litwin&#39;s Sorted Linear Hash Table. I have a hackish implementation on hackage somewhere, but bear in mind it was the first piece of Haskell I&#39;d ever written and the STM version I have bottlenecks on the root of the tree, so would be better served by multiple root TVars.<br>
<br>I can&#39;t find it on Hackage, but here it is:<br><br><a href="http://comonad.com/haskell/thash/">http://comonad.com/haskell/thash/</a><br><br>-Edward Kmett<br><br></div></div>