<div dir="ltr">On Tue, Jul 16, 2013 at 10:31 AM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 16 July 2013 11:46, John Lato <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>> wrote:<br>
> In my tests, using unordered-containers was slightly slower than using Ord,<br>
> although as the number of repeated elements grows unordered-containers<br>
> appears to have an advantage. I'm sure the relative costs of comparison vs<br>
> hashing would affect this also. But both are dramatically better than the<br>
> current nub.<br>
><br>
> Has anyone looked at Bart's patches to see how difficult it would be to<br>
> apply them (or re-write them)?<br>
<br>
</div>If I understand correctly, this function is proposed to be added to<br>
Data.List which lives in base... but the proposals here are about<br>
using either Sets from containers or HashSet from<br>
unordered-containers; I thought base wasn't supposed to depend on any<br>
other package :/<br></blockquote><div><br></div><div style>That was one of the points up for discussion: is it worth including a subset of Set functionality to enable a much better nub in base? Is it even worth having Data.List.nub if it has quadratic complexity?</div>
<div style><br></div><div style>As an alternative, Bart's proposal was for both including ordNub in containers and an improved nub (with no dependencies outside base) in Data.List. Unfortunately the patches are quite old (darcs format), and I don't know how they'd apply to the current situation.</div>
</div></div></div>