On Apr 16, 8:25 am, Razvan 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 behavior appears
On Sat, Apr 17, 2010 at 1:05 AM, Per Vognsen 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 0
with your queried
> 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
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
On Sat, Apr 17, 2010 at 12:01 AM, Sean Devlin 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 to give well-defined re
CORRECTION, DON'T SHOOT!!
I should have order & value, not order & identity.
On Apr 16, 1:01 pm, Sean Devlin 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
> that a comparator v
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,
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. That
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 key
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)
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.
Persiste
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.
Razvan
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To pos
12 matches
Mail list logo