in reply to Re: "Divide" challenge
in thread "Divide" challenge
Brute forcing is not quite as straight forward as one might think :-)
The solution above is working a lot harder than is really necessary, even for a brute force solution. If I understand the problem correctly, we are trying to minimize the data exchanged between the groups. Therefore what matters is the sum of data exchanged between the two groups, not the internal composition of each group.
This lets us significantly reduce the potential solution space. The combination generator above generates every single permutation of 4 elements drawn from 8, not just every single combination. For example, this is the list of combinations produced by gen_set([0..3],[],2, \@combos);. There are 12 items, but if we disregard order only 6 would count.
<0 1> <0 2> <0 3> <1 0> <1 2> <1 3> <2 0> <2 1> <2 3> <3 0> <3 1> <3 2>
In actual fact, though we need only half of the combinations, even after ignoring order. This is because our second bag is always the complement of our first bag. Since sums are commutative, trying out the division (bag 1, complement of bag 1) is going to result in the exact same data flow sum as the division (complement of bag 1, bag 1)
Best, beth
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: "Divide" challenge
by bellaire (Hermit) on Mar 10, 2009 at 18:11 UTC | |
Re^3: "Divide" challenge
by repellent (Priest) on Mar 12, 2009 at 21:53 UTC |