On Jan 26, 2009, at 4:24 PM, Mark Engelberg wrote:
>
> Hey, I just looked back at the original post that started the thread.
> At some point, I had changed my function so (cartesian-product)
> returned nil instead of (nil), but based on Jason's post, I've changed
> it back in another paste annotat
Hey, I just looked back at the original post that started the thread.
At some point, I had changed my function so (cartesian-product)
returned nil instead of (nil), but based on Jason's post, I've changed
it back in another paste annotation.
--~--~-~--~~~---~--~~
Y
I updated the paste with the changes we've discussed.
http://paste.lisp.org/display/74134#3
I'll keep playing around to see if I can get it faster, but so far,
this is the fastest way I've found to generate the cartesian product
in standard order.
--~--~-~--~~~---~--
On Jan 26, 2009, at 10:28 AM, Mark Engelberg wrote:
>
> I've tested that already, and it takes even longer for all but trivial
> inputs, because rec now prevents the combinations sequence from being
> garbage collected, and the memory allocation bogs things down
> tremendously.
Ah, I noticed the
I've tested that already, and it takes even longer for all but trivial
inputs, because rec now prevents the combinations sequence from being
garbage collected, and the memory allocation bogs things down
tremendously.
On Mon, Jan 26, 2009 at 10:26 AM, Jason Wolfe wrote:
>
>> Also, it's worth poin
> Also, it's worth pointing out that your newer version prints the
> combinations out in a non-standard order.
Good point ... I shouldn't have tried to avoid adding the "let":
(defn combinations "Take a seq of seqs and return a lazy list of
ordered combinations (pick 1 from each seq)"
[seq
>
> For simple inputs, the two approaches have similar performance. On
> complex inputs, my tests show the iterative version tends to run about
> twice as fast.
>
> Try running on an extreme input like:
> ["ACDFG" "A" "B" "C" "D" "E" "F" "ABCD" "G" "H" "I" "ABEG" "J" "K"
> "BCDE" "L" "ABCDG" "M"
Also, it's worth pointing out that your newer version prints the
combinations out in a non-standard order. I don't know whether people
should really rely on the order, but I think most people would expect
it to print out in the same order as a series of nested for loops.
--~--~-~--~~
For simple inputs, the two approaches have similar performance. On
complex inputs, my tests show the iterative version tends to run about
twice as fast.
Try running on an extreme input like:
["ACDFG" "A" "B" "C" "D" "E" "F" "ABCD" "G" "H" "I" "ABEG" "J" "K"
"BCDE" "L" "ABCDG" "M" "EF" "NABC" "AB
OK, cartesian_product it is.
Two comments on your version. First, unlike mine (and the current
"combinations"), it takes a single argument, a seq of seqs (rather
than multiple seq arguments); which of these ways is preferred?
Second, I had the clauses of my for loop backwards, which was slowing
On Fri, Jan 23, 2009 at 11:43 PM, wrote:
> I think the usual mathematical name is be cartesian-product (or maybe
> cross-product), although selections is OK with me too.
Yes, now that you've reminded me, I agree that cartesian-product is
the usual mathematical name, and that would probably be m
> On Fri, Jan 23, 2009 at 8:49 PM, Chouser wrote:
>> This is the best version?
>
> Depends on your definition of "best".
>
> I just posted a version at http://paste.lisp.org/display/74134 which
> is many times faster.
I haven't had a chance to look at that in detail yet, but I'm 100% in
favor of
On Fri, Jan 23, 2009 at 8:49 PM, Chouser wrote:
> This is the best version?
Depends on your definition of "best".
I just posted a version at http://paste.lisp.org/display/74134 which
is many times faster.
Also, I have to say that calling this function "combinations" is
fairly nonstandard. Usu
On Fri, Jan 23, 2009 at 1:11 PM, Stephen C. Gilardi wrote:
>
> Please do enter it as an issue. I'd be interested in hearing from Chouser
> before making the change. He added combinations to lazy-seqs.
I did what now? My memory must be going. Here are some other
implementations I apparently wen
>
> On Jan 23, 2009, at 1:11 PM, Stephen C. Gilardi wrote:
>
>> I'd be interested in hearing from Chouser before making the change.
>> He added combinations to lazy-seqs.
>
> I think it's quite cool that simply removing the "when" accomplishes
> this.
Yes, exactly :) Returning nil for no-arg
On Jan 23, 2009, at 1:11 PM, Stephen C. Gilardi wrote:
I'd be interested in hearing from Chouser before making the change.
He added combinations to lazy-seqs.
I think it's quite cool that simply removing the "when" accomplishes
this.
--Steve
smime.p7s
Description: S/MIME cryptographic
On Jan 23, 2009, at 12:53 PM, Jason Wolfe wrote:
Just to clarify: I dont' care what the type of the output is. I guess
(seq [[]]) would actually be more consistent with the existing
function. The point is that the output of 0-arg combinations should
be a seq containing an empty vector (or wha
Just to clarify: I dont' care what the type of the output is. I guess
(seq [[]]) would actually be more consistent with the existing
function. The point is that the output of 0-arg combinations should
be a seq containing an empty vector (or whatever other types, I don't
care), not an empty seq.
I just got bit by (clojure.contrib.lazy-seqs/combinations) returning
nil, not [[]] as I expected. I could see arguments for either being
the "correct" output, but let me give my case for [[]].
In my mind, asking what the output of (combinations) should be is
completely analogous to asking what t
19 matches
Mail list logo
