On Wed, Dec 16, 2009 at 3:04 PM, ajay gopalakrishnan ajgop...@gmail.com wrote:
If the sets data structure is also not shared, then the paper I mentioned
(link provided earlier) is one of the fastest to date. And it is very small
easy to implement.
I think an implementation of persistent sets
Hi,
Here's the example of what I meant in the topic title:
Let's say we have a set s1 that have 3 elements: #{obj1, obj2, obj3}
I add a few elements to it and get s2 #{obj1, obj2, obj3, obj4, obj5}
It is important to notice that, because s2 has been created by
modifying s1, it reuses its
Set equality requires the complete traversal of the set, and will
always be O(n). However, there are shortcuts for determining if they
are not equal. You could use the following test
(if (first (remove set1 set2))
:not-equal
(if (first (remove set2 set1))
:not-equal
:equal))
remove
Hi,
On Dec 16, 3:45 pm, Sean Devlin francoisdev...@gmail.com wrote:
Set equality requires the complete traversal of the set, and will
always be O(n).
I think, what Dragan was refering to is the shared structure in a set.
Let's say you have to two sets A' and A'' which evolved from set A by
In general, straight equality is efficient for Clojure data
structures. For example, the equals() implementation for sets checks
type, size, and hash code before examining the set elements.
Determining that two sets are equal is still O(n), but determining
that they are NOT equal is usually O(1).
Oh, I get it. Thanks Meikel.
I imagine this is possible if you drill into the guts of
PersistentHaspMap, but I would strongly discourage the behavior in
user code. Perhaps as an upgrade to the object itself? There is a 1%
chance that this could be a language upgrade, assuming it works across
I imagine this is possible if you drill into the guts of
PersistentHaspMap, but I would strongly discourage the behavior in
user code. Perhaps as an upgrade to the object itself? There is a 1%
chance that this could be a language upgrade, assuming it works across
the board. I would tread
Yes, the true/false for equality is not a problem.
I am looking for a shortcut that finds different elements more
efficiently. So, the sets are different, but I want to get hold of
elements that are in s2 but not in s1.
On Dec 16, 8:38 pm, Richard Newman holyg...@gmail.com wrote:
I imagine
Your argument is right and it is a good idea to take advantage of the shared
structure to calculate differences. However, it is important to remember
that is is just a special case and I don't expect that whenever you want to
calculate a difference between two sets, you always compare between the
If the sets data structure is also not shared, then the paper I mentioned
(link provided earlier) is one of the fastest to date. And it is very small
easy to implement.
On Wed, Dec 16, 2009 at 2:59 PM, Dragan Djuric draga...@gmail.com wrote:
Yes, the true/false for equality is not a problem.
10 matches
Mail list logo
