Here's the source for sorted-set-by:
(defn sorted-set-by
Returns a new sorted set with supplied keys, using the supplied
comparator.
([comparator keys]
(clojure.lang.PersistentTreeSet/create comparator keys)))
This is because your comparator is saying that everything is equal.
It doesn't seem confusing to me. You are taking complete control of
the set's local notion of ordering and equality. This is what I'd
expect.
Here's an example. First, a handy little function from Haskell:
(defn on [key f]
#(apply f (map key %)))
Then:
user (sorted-set-by (on :id compare)
Why should sorting be related to the primary key? You should be able
to sort on any attribute. If you wanted to sort a set of people by age
would it make sense to only retain one person of each age? Sort order
and identity should be orthogonal. Besides, if you need a collection
based on primary
Maybe the example was poorly picked but the point stands: if you're
asking for a sorted set based on a comparator, you should expect
duplicate elements as dictated by comparator to be eliminated. If you
wanted to sort a set of people by age, you wouldn't use a sorted set
but a sorted sequence.
I think the fns you're interested in are sort and sort-by, not sorted-
set-by.
I know you might not like it, but there is a convention in JavaLand
that a comparator value of 0 is identical in a sorted collection.
This causes orthogonal concepts of order identity to be entwined.
Sean
On Apr 16,
CORRECTION, DON'T SHOOT!!
I should have order value, not order identity.
On Apr 16, 1:01 pm, Sean Devlin francoisdev...@gmail.com wrote:
I think the fns you're interested in are sort and sort-by, not sorted-
set-by.
I know you might not like it, but there is a convention in JavaLand
On Sat, Apr 17, 2010 at 12:01 AM, Sean Devlin francoisdev...@gmail.com wrote:
I know you might not like it, but there is a convention in JavaLand
that a comparator value of 0 is identical in a sorted collection.
It's not a Java convention. It's intrinsic to the business of sorting.
For sorting
The problem is you're unnecessarily conflating the value by which to
base a sort (x and y in your example) with the elements of the set.
Equality and ordinality are not the same thing. It should be
perfectly reasonable to hand someone a set of unique objects sorted by
some non-unique attribute of
Equality and ordinality are not the same thing. It should be
perfectly reasonable to hand someone a set of unique objects sorted by
some non-unique attribute of the elements of the set.
Sure, it's perfectly reasonable but it implies a different data
structure. It sounds like you want a data
On Sat, Apr 17, 2010 at 1:05 AM, Per Vognsen per.vogn...@gmail.com wrote:
You can only do slow
linear-time lookups by traversing the tree's nodes exhaustively.
Correction: You do not have to do a linear search on the whole tree
but only on the subset of the tree for which the comparator returns
On Apr 16, 8:25 am, Razvan gigi.clan...@gmail.com wrote:
Hi,
Is this the intended behavior?
(sorted-set-by (constantly 0) 1 2 3 4) returns #{1}.
I would expect the set to contain all the elements, and the comparator
to only affect sort order.
I expected the same thing at first, but the
11 matches
Mail list logo
