On Jan 24, 2009, at 6:01 PM, Stephen C. Gilardi wrote:
> On Jan 24, 2009, at 8:11 PM, Jason Wolfe wrote:
>> Finally, I don't know how to make a patch, and found nothing in a
>> quick search of the wiki/newsgroup/website. I heard "Git" floating
>> around somewhere earlier; am I to check out the S
On Jan 24, 2009, at 8:11 PM, Jason Wolfe wrote:
Finally, I don't know how to make a patch, and found nothing in a
quick search of the wiki/newsgroup/website. I heard "Git" floating
around somewhere earlier; am I to check out the SVN with git-svn and
make a patch that way?
To prepare a patch,
> I'm all for optimizing for size here, however, the fact that these
> functions happen to work when the second argument is not a set is an
> implementation artifact and not a promise of the interface, so I'm not
> in favor of the set? testing or any other accommodation of that.
OK, from that I t
On Jan 23, 5:42 pm, Jason Wolfe wrote:
> > I appreciate your desire to contribute, but Clojure is not just about
> > your needs. You have flooded the group with every idea you have, some
> > are bugs (important), some are good ideas, some not, but there are
> > simply too many to address at the
On Jan 23, 2009, at 7:56 PM, e wrote:
(ns my-ns
(:use [clojure.set :exclude (difference)]
[clojure.contrib.set :only (difference)]))
Did you have to say ":exclude" or does the last thing override?
I had to say :exclude. :use makes a call to refer whic
>
> (ns my-ns
>(:use [clojure.set :exclude (difference)]
> [clojure.contrib.set :only (difference)]))
>
Did you have to say ":exclude" or does the last thing override?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
> Hi Jason,
>
> Thanks very much for all your recent thought, work, and postings.
>
> I think it makes sense for clojure-contrib to be much more agile in
> accepting new, experimental, and incrementally improved code than
> Clojure proper. Things in contrib are always optional for end users s
> I appreciate your desire to contribute, but Clojure is not just about
> your needs. You have flooded the group with every idea you have, some
> are bugs (important), some are good ideas, some not, but there are
> simply too many to address at the rate you are producing them.
OK, I am sorry. I
On Jan 23, 2009, at 3:23 PM, Jason Wolfe wrote:
OK, if these are not wanted in core right now, will anyone sign off
for adding them to clojure.contrib?
I can't say I like the idea of having two sets of functions that do
exactly the same thing, but ... sometimes you just don't want things
to ru
On Jan 23, 4:19 pm, Jason Wolfe wrote:
> > On Fri, Jan 23, 2009 at 12:23 PM, Jason Wolfe
> > wrote:
>
> >> OK, if these are not wanted in core right now, will anyone sign off
> >> for adding them to clojure.contrib?
>
> > Well, *I* want these changes you've proposed in the core, but of
> > cou
>
> On Fri, Jan 23, 2009 at 12:23 PM, Jason Wolfe
> wrote:
>>
>> OK, if these are not wanted in core right now, will anyone sign off
>> for adding them to clojure.contrib?
>>
>
> Well, *I* want these changes you've proposed in the core, but of
> course, I'm not in charge.
Thanks.
> I guess t
On Fri, Jan 23, 2009 at 2:52 PM, Mark Engelberg wrote:
>
> On Fri, Jan 23, 2009 at 12:23 PM, Jason Wolfe
> wrote:
> >
> > OK, if these are not wanted in core right now, will anyone sign off
> > for adding them to clojure.contrib?
> >
>
> Well, *I* want these changes you've proposed in the core, b
On Fri, Jan 23, 2009 at 12:23 PM, Jason Wolfe wrote:
>
> OK, if these are not wanted in core right now, will anyone sign off
> for adding them to clojure.contrib?
>
Well, *I* want these changes you've proposed in the core, but of
course, I'm not in charge. I guess the real question is, what is
OK, if these are not wanted in core right now, will anyone sign off
for adding them to clojure.contrib?
I can't say I like the idea of having two sets of functions that do
exactly the same thing, but ... sometimes you just don't want things
to run ~1000 times slower than they should.
-Jason
--~
I think that having efficient algorithms for the fundamental data
structures is extremely important.
But Rich and the Contributers must have tons of other stuff to worry
about. In the meantime I will
use Jason's fix.
On Jan 20, 8:27 pm, Mark Engelberg wrote:
> I say "thumbs up" to this proposal.
I say "thumbs up" to this proposal. Sets really should test for the
size of the two inputs, and adjust the algorithm accordingly.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this grou
On Jan 20, 4:44 pm, Jason Wolfe wrote:
> Apologies for multiple posts; I will try to thoroughly investigate
> things before starting posting next time. Anyway, to round out the
> thread, here are corresponding results for intersection and union:
Well, that didn't last too long ... from now on
Apologies for multiple posts; I will try to thoroughly investigate
things before starting posting next time. Anyway, to round out the
thread, here are corresponding results for intersection and union:
(defn- fast-intersection- "Expects s1 and s2 sets, s1 bigger than
s2." [s1 s2]
(reduce (fn
One caveat: I do like the fact that the set operations currently don't
require the second argument to be a set. In the case that it's not, I
believe the current implementations (at least for difference) are as
good as it gets.
So, I guess fast-difference should read:
(defn fast-difference "Like
I ran into a situation in my application where I wanted to take a set-
difference between a small set and a large set. In this circumstance,
clojure.set/difference is needlessly slow. Because of this, in
general, a sequence of n clojure.set operations may run in O(n^2) time
when O(n) is easily a
20 matches
Mail list logo
