Comments on: Calculating Combinations the Erlang Way

By: Semergence » Blog Archive » Calculating Combinations Using Java and Lots of Bits

Wed, 22 Oct 2008 02:32:58 +0000

[…] was feeling nostalgic and went back to see how I calculated combinations in Erlang and combinations in Ruby. I wanted to see if there was an efficient way to do it without resorting […]

By: David Mercer

David Mercer — Mon, 06 Aug 2007 15:20:11 +0000

I might be wrong here, but I think listing the combinations of any more than, say, 20 elements is unreasonable. There are 1,048,576 combinations of 20 elements. Your example of 100 elements would produce a list of length 1,267,650,600,228,229,401,496,703,205,376 elements (each element being itself a list of 0–100 elements). I don’t know the statistics on the amount of memory in the world (or the number of electrons in the universe), but I am guessing that is much larger than any memory in the universe can hold.

For that reason, worrying whether the function is tail-recursive is probably not important, since you’re not going to have that many levels of recursion. If you do manage to procure enough memory to run the calculation, the stack space taken up by the recursion is insignificant next to the memory requirements of your result.

By: Ben Munat

Ben Munat — Sun, 05 Aug 2007 20:23:21 +0000

Wow, I didn’t think it was possible to get it that (@Jason/David) compact. In my aborted attempt, I was trying the “local function with accumulator” approach. I need to work on my list comprehension mojo… seems very powerful indeed.

One question though: is the solution here tail recursive? If I’m understanding it right, I don’t think it is… process() is called recursively with the tail, and then as these calls exit, the results are used by the list comprehension and passed to append.

To test my theory out, I figured I’d see how it does with a bit longer list…. like, uh, a hundred or so elements. The answer is “don’t do that”… it makes your computer very very unhappy.

So, anyone have another version — even if it’s not quite so compact — that isn’t a potential DOS?

By: Semergence » Blog Archive » Calculating Combinations In Ruby From Erlang

Sun, 05 Aug 2007 07:53:59 +0000

[…] thanks to the many people (here and here) that provided their versions of an erlang way to calculate combinations, I’ve […]

By: David Mercer

David Mercer — Fri, 03 Aug 2007 19:17:00 +0000

This one's a higher golf score (50), but much more efficient, since it only calls itself once. Thanks to Jason's comment above for the idea.

c([])->[[]];c([H|T])->[G++C||G<-[[H],[]],C<-c(T)].

By: sethladd

sethladd — Fri, 03 Aug 2007 19:15:01 +0000

Jason, I bow down to you, sir.

By: sethladd

sethladd — Fri, 03 Aug 2007 19:11:58 +0000

David, looking good! I’ve read that using ++ like that is bad form. Of course, as an erlang n00b, what do I know?

By: David Mercer

David Mercer — Fri, 03 Aug 2007 19:05:38 +0000

OK, thanks to Masonium's comment, I have now managed to golf this problem down to 45 characters, and I don't even need the mask/1 function I defined earlier but then didn't count against my score. Here is the all-in-one combination generator function:

c([])->[[]];c([H|T])->[[H|C]||C<-c(T)]++c(T).

By: Jason

Jason — Fri, 03 Aug 2007 19:00:53 +0000

combos([]) -> [[]]; combos([H|T]) -> lists:append([[[H|L],L] || L <- combos(T)]).

By: David Mercer

David Mercer — Fri, 03 Aug 2007 18:54:04 +0000

I sat there and looked at that filter, sure that there was a shorter way to do it, but couldn’t figure it out. Soon after I posted, I read http://weblog.hypotheticalabs.com/?p=137, which explained that list comprehensions can be used for filtering, too. Using those techniques, I have my golf score down to 66:

c(L)->[[V||{V,true}<-C]||C<-[lists:zip(L,M)||M<-mask(length(L))]].

Of course, this still relies on my definition of mask/1, which I’m not counting against me. Masonium’s post above, though, gives me some ideas.