On 2010 Apr 29, at 2:17 AM, Mark Engelberg wrote:
On Wed, Apr 28, 2010 at 10:49 PM, Douglas Philips wrote:
What is the purpose, goal, design-rationale of not making seq-
contains? fast
on maps or sets?
I think Rich's point is that if seq-contains? is sometimes fast and
sometimes slow, then it makes it harder to reason about a program that
uses seq-contains?.
If I'm writing seq-friendly functions, what you're saying is that I am
guaranteed to be always slow?
That if the code using my function(s) passes in a set instead of a
vector there shouldn't be a speed up?
seq-contains? always does a linear search.
I'm not arguing against that, but apparently it is such a popular
straw man that I don't have to. :)
Is the contract for seq-contains that it will always examine every
element, or is it permitted to stop early if it finds a match? Is it
forbidden for range and seq-contains? to exploit the kind of protocol-
ish benefits that Stuart showed in his video with reduce and strings?
So if you see seq-contains? in your code, this
serves as a big red flag that either you should be using a set data
structure and contains?, or you better be sure your sequence is
relatively small.
Maybe. But maybe it is a "red flag" that I'm accepting any kind of
seq, and that my code will work for whatever seq type makes sense for
the problem my function is being used to help solve.
If seq-contains? sometimes had good performance, then people would
start using a mixture of seq-contains? and contains? for sets and
maps, and it would be less clear when you were using seq-contains?
"improperly".
Oh, please. First you say I'm too stoopid to profile my code :), and
that I won't be able to reason about it, and now you're saying that I
will profile it but come to some broken conclusions? I already know
that if I use a "may have to check every element" containment function
that it might <dramatic music/> have to check every element. At least
have the guts to make the slow function guaranteed slow (it ALWAYS
checks every element) so that I don't ever get some potentially
unclear idea about what the performance will be, and that I should
never use it on infinite sequences. Sheesh.
-Doug
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
