<br><div class="gmail_quote">On Tue, Jun 22, 2010 at 4:18 PM, Andrew Coppin <span dir="ltr"><<a href="mailto:andrewcoppin@btinternet.com">andrewcoppin@btinternet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
What the...? <br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Oh, I see. It uses another package to handle the tricky sorting and searching stuff. Well, yeah, that would make the code a bit shorter... ;-)<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Even so, it's not nearly as elegant to behold as, say, the quicksort algorithm, despite being of roughly similar complexity. Still, it's shorter than what I had.</blockquote><div class="h5"><br>I would argue that quicksort is considerably simpler, as it doesn't have to maintain an explicit tree, lookup and merge values, deal with bits, etc.<br>
<br>For something, perhaps closer in spirit to quicksort, and still compression-oriented, I have an implementation of LZ78 for decompressing streams directly into
a monoid, rather than reconstituting the result, which also winds up
remarkably terse and a great deal more general than its imperative
counter-parts. ;)<br>
<br>
<a href="http://hackage.haskell.org/packages/archive/monoids/0.1.36/doc/html/src/Data-Generator-Compressive-LZ78.html">http://hackage.haskell.org/packages/archive/monoids/0.1.36/doc/html/src/Data-Generator-Compressive-LZ78.html</a><br>
<br>-Edward Kmett<br></div></div><br>