On 4/29/2010 6:49 PM, Michael Gardner wrote:
+1. I can't imagine any use case for looking up a whole [key, value] pair in a
hash-map.
Agreed. The whole point of a map is to provide key-based lookup.
Iterating over all (key, value) pairs in the map makes sense,
not so much looking for one in pa
If "contains?" is a sensible name for that function, then surely
"seq-contains?" cannot be a sensible name for a function which checks
a totally different sort of "containment"?
Also, if it is possible to view "seq-contains?" as a sensible enough
name for a core library function with sequential se
On Apr 30, 2010, at 14:33 , Rich Hickey wrote:
>
> 'contains?' and 'get' abstract over fast lookup. They are polymorphic on the
> collection type and on the nature of the looked-up thing. For maps the
> looked-up thing is a key, for sets: a value, for vectors, strings and arrays:
> an index.
Clojure embraces this "laziness":
user=> (get #{:foo :bar} :foo)
:foo
'get uses a "key" to return a "value". A vector is not a map is not a
set, but all of them can have their values accessed in constant-time
using a "key".
On Apr 30, 3:14 pm, "Steven E. Harris" wrote:
> Phil Hagelberg write
Phil Hagelberg writes:
> Actually I do consider sets to have keys, since internally they are
> implemented using maps, so the exact same semantics apply for their
> lookup. They're just maps where the key and value are the same thing:
But that implementation is one of convenience, of possibly ad
On Apr 29, 3:21 am, ataggart wrote:
> Functions named contains-key? and contains-val? would make a lot more
> sense to me than the current contains? and new seq-contains?.
Amen. Even independent of any performance expectations.
--
You received this message because you are subscribed to the Go
On Apr 30, 2010, at 6:33 AM, Rich Hickey wrote:
> Would contains-val? be fast for sets? As a user of sets, I consider them
> collections of values, and I absolutely would reach for contains-val? in any
> library that had it, for use with sets. If so, and I used contains-val?, and
> I moved cod
On 2010 Apr 30, at 7:33 AM, Rich Hickey wrote:
> People don't consider sets, vectors, arrays or strings to have
'keys'.
That is not consistent with the documentation:
Sets: http://clojure.org/data_structures:
Sets support 'removal' with disj, as well as contains? and get, the
latter returni
On Apr 30, 4:33 am, Rich Hickey wrote:
> People don't consider sets, vectors, arrays or strings to have 'keys'.
> But, like maps, they all support fast lookup of some sort.
But of course we do. I point to the doc for contains? and get:
Usage: (contains? coll key)
Returns true if key is prese
On Fri, Apr 30, 2010 at 5:18 AM, Laurent PETIT wrote:
> While it sounds soo evident now that you say that explicitly ( the
> contains? / get pair ), it may be good to reflect that in the docs of
> the functions rather than just keep this knowledge here ?
Agreed. This explanation of the relations
On Fri, Apr 30, 2010 at 4:33 AM, Rich Hickey wrote:
> On Apr 29, 2010, at 4:21 AM, ataggart wrote:
>> Functions named contains-key? and contains-val? would make a lot more
>> sense to me than the current contains? and new seq-contains?. Anyone
>> looking at contains-val? should expect it to be O(
Hi,
On Thu, Apr 29, 2010 at 7:48 AM, Meikel Brandmeyer wrote:
>
> On 29 Apr., 01:38, Mark Engelberg wrote:
>
> > 1. Don't include seq-contains? The behavior you want can usually be
> > achieved by using (some #{item} coll). Disadvantage - if you're
> > testing to see if the collection contains
On Apr 29, 2010, at 2:19 PM, MarkSwanson wrote:
> On Apr 29, 4:21 am, ataggart wrote:
>> I know it won't matter, but for posterity if nothing else...
>>
>> Functions named contains-key? and contains-val? would make a lot more
>> sense to me than the current contains? and new seq-contains?. Any
2010/4/30 Rich Hickey :
>
> On Apr 29, 2010, at 4:21 AM, ataggart wrote:
>
>> I know it won't matter, but for posterity if nothing else...
>>
>> Functions named contains-key? and contains-val? would make a lot more
>> sense to me than the current contains? and new seq-contains?. Anyone
>> looking
On Apr 29, 2010, at 4:21 AM, ataggart wrote:
I know it won't matter, but for posterity if nothing else...
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should expect it to be
Iterating through the pairs is useful. Asking if a given [k, v] is
included is not - you can just ask if (= (assoc k) v) instead.
It'd be nice if (contains-val) returned the key(s) as its true result,
but probably not useful enough to warrant the complexity of dealing
with false keys, explicit tr
> +1. I can't imagine any use case for looking up a whole [key, value] pair in
> a hash-map.
Actually this is quite useful when you want to do something for each
value and need to know the key as well - for example copy some
key/value pairs to another map
Boris
>
> --
> You received this message
On Apr 29, 4:21 am, ataggart wrote:
> I know it won't matter, but for posterity if nothing else...
>
> Functions named contains-key? and contains-val? would make a lot more
> sense to me than the current contains? and new seq-contains?. Anyone
> looking at contains-val? should expect it to be O
On Apr 29, 2010, at 3:21 AM, ataggart wrote:
> I know it won't matter, but for posterity if nothing else...
>
> Functions named contains-key? and contains-val? would make a lot more
> sense to me than the current contains? and new seq-contains?. Anyone
> looking at contains-val? should expect it
(send contains-val? inc)
On Apr 29, 9:06 am, Douglas Philips wrote:
> On 2010 Apr 29, at 4:21 AM, ataggart wrote:
>
> > Functions named contains-key? and contains-val? would make a lot more
> > sense to me than the current contains? and new seq-contains?. Anyone
> > looking at contains-val? shou
On Apr 29, 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, th
On 2010 Apr 29, at 7:52 AM, Laurent PETIT wrote:
2010/4/29 Mark J. Reed :
I like this proposal. I'd make contains? an alias for contains-key?
with a deprecation warning, and just forget about seq-contains? in
favor of contains-val?
This makes a lot of sense to me.
(and have, as suggested by a
On 2010 Apr 29, at 4:21 AM, ataggart wrote:
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should expect it to be O(n). The only
effective difference would be that the test value
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
Thinking about this one.
I like this proposal. I'd make contains? an alias for contains-key?
with a deprecation warning, and just forget about seq-contains? in
favor of contains-val?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
2010/4/29 Mark J. Reed :
> I like this proposal. I'd make contains? an alias for contains-key?
> with a deprecation warning, and just forget about seq-contains? in
> favor of contains-val?
This makes a lot of sense to me.
(and have, as suggested by ataggart, contains-key? complain if passed a seq
I like this proposal. I'd make contains? an alias for contains-key?
with a deprecation warning, and just forget about seq-contains? in
favor of contains-val?
On Thursday, April 29, 2010, ataggart wrote:
> I know it won't matter, but for posterity if nothing else...
>
> Functions named contains-k
On Apr 29, 2010, at 1:57 AM, Meikel Brandmeyer wrote:
Hi,
On 29 Apr., 01:43, Stuart Halloway wrote:
I'll wait for Rich to maybe chime in on seq-contains?. Other than
seq-
contains? are people liking the new fns? Anybody having issues we
didn't anticipate?
I was a little bit surprised ab
I know it won't matter, but for posterity if nothing else...
Functions named contains-key? and contains-val? would make a lot more
sense to me than the current contains? and new seq-contains?. Anyone
looking at contains-val? should expect it to be O(n). The only
effective difference would be tha
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
use
Hi,
On 29 Apr., 01:43, Stuart Halloway wrote:
> I'll wait for Rich to maybe chime in on seq-contains?. Other than seq-
> contains? are people liking the new fns? Anybody having issues we
> didn't anticipate?
I was a little bit surprised about map-indexed and keep-indexed.
Why specialised func
On 2010 Apr 28, at 11:04 PM, Rich Hickey wrote:
It is an important aspect of Clojure that, in general, performance
guarantees are part of the semantics of functions. In particular,
functions are not supported on data structures where they are not
performant.
Understood. That isn't the poin
Hi,
On 29 Apr., 01:38, Mark Engelberg wrote:
> 1. Don't include seq-contains? The behavior you want can usually be
> achieved by using (some #{item} coll). Disadvantage - if you're
> testing to see if the collection contains nil, that won't work.
Not entirely correct. (some #(= % item) coll)
On 2010 Apr 28, at 7:38 PM, Mark Engelberg wrote:
But I think you're not fully appreciating the complexity of the
situation. This is not just about performance, but a question of two
different possible semantics for "contains?", which is why it can't
*only* be addressed with a protocol.
...
On Apr 28, 7:17 pm, Douglas Philips wrote:
> On 2010 Apr 28, at 6:55 PM, Stuart Halloway wrote:
>
> > Specializations are available where there is a clear use case, e.g.
> > contains?, peek (instead of last), disj, etc.
> ...
> > Tying to concrete types is limiting. *Never* having special purpo
On Apr 28, 2010, at 6:38 PM, Mark Engelberg wrote:
> 2. Rename contains? to contains-key? and make a function with the new
> semantics called contains? Disadvantage - breaks existing code.
You could also alias contains? to contains-key?, use seq-contains? (or some
other new name) for this new
Wow, and I thought this was a sore subject before, when there was no
seq-contains? and its absence was always a Top 5 FAQ. :-)
I'll wait for Rich to maybe chime in on seq-contains?. Other than seq-
contains? are people liking the new fns? Anybody having issues we
didn't anticipate?
Stu
O
On Wed, Apr 28, 2010 at 2:39 PM, Douglas Philips wrote:
> If some function I call uses seq-contains? (so that it can get all the
> wonderful seq-ness abstractness clojure offers) I should have to know that
> internal detail and not pass in a map or set? or worse, fail to get an
> optimization i
On 2010 Apr 28, at 6:06 PM, Meikel Brandmeyer wrote:
Ah, ok. I misunderstood what you were saying. But I think it doesn't
change the argumentation. If seq-contains? was fast on maps and sets,
people would abandon contains? because seq-contains? is "always
right":
works on seqs, fast on maps and
On 2010 Apr 28, at 6:55 PM, Stuart Halloway wrote:
Specializations are available where there is a clear use case, e.g.
contains?, peek (instead of last), disj, etc.
...
Tying to concrete types is limiting. *Never* having special purpose
fns that know about performance characteristics is also
Another way to put it: If you wrote a protocol to pick a fast
implementation based on type, then seq-contains? would be the fn
that the protocol would call if it couldn't find anything faster.
There have to be primitive things somewhere...
If so, then why isn't there a vector-first and a li
On 2010 Apr 28, at 6:10 PM, Stuart Halloway wrote:
The "seq" in "seq-contains?" says "I want a sequential search."
Protocols *could* make this do something different, but that would
violate the contract of this function.
How would having it work faster if passed a set or map violate that?
The "seq" in "seq-contains?" says "I want a sequential search."
Protocols *could* make this do something different, but that would
violate the contract of this function.
Another way to put it: If you wrote a protocol to pick a fast
implementation based on type, then seq-contains? would be t
Hi,
On Wed, Apr 28, 2010 at 05:39:37PM -0400, Douglas Philips wrote:
> Stuart's comment was to not use seq-contains? on maps or sets.
> There is no reason that it cannot be the same speed as contains? if
> a set or map is passed in.
Ah, ok. I misunderstood what you were saying. But I think it do
On 2010 Apr 28, at 5:32 PM, Meikel Brandmeyer wrote:
On Wed, Apr 28, 2010 at 05:26:46PM -0400, Douglas Philips wrote:
How is having an optimized version of seq-contains? for sets/maps
any different from what Stuart showed in his video, where reduce can
have a specialization that is faster on so
Hi,
On Wed, Apr 28, 2010 at 05:26:46PM -0400, Douglas Philips wrote:
> How is having an optimized version of seq-contains? for sets/maps
> any different from what Stuart showed in his video, where reduce can
> have a specialization that is faster on some types?
A faster reduce is still O(N). If
On 2010 Apr 28, at 5:14 PM, Meikel Brandmeyer wrote:
If you have a map or a set looking up a key is fast. So contains? is
fast (read O(1) resp. something like O(log32 N)). seq-contains? does
a linear search through a sequence. That is O(N). Protocols cannot
change this.
How is having an optimiz
Hi,
On Wed, Apr 28, 2010 at 05:06:21PM -0400, Douglas Philips wrote:
> Wait, what? Why should seq-contains? be slower than contains? Isn't
> this exactly the kind of thing that protocols are supposed to be
> solving? Your nice video showed that very thing, right?
If you have a map or a set looki
On 2010 Apr 28, at 4:31 PM, Stuart Halloway wrote:
After review, several seq functions from clojure-contrib have been
promoted to clojure [1], [2], [3]. Hopefully the FAQ below will
answer the major questions you may have:
Cool!
3. Why did some of the fn names change?
...Similarly, includ
49 matches
Mail list logo
