My submission is attached. The key insight: if you start with the
largest values you can divide the loot one gang member at a time without
fear of getting wrongly stuck. For an example of being wrongly stuck,
consider:
% ruby loot.rb 3 1 1 1 2 2 2
The shares will all have to total 3, but if you start with the light end
you might end up with (1, 1, 1) for the first guy, and then the rest of
the loot can’t be evenly split. Starting with the heavy end, though,
gets you to the right place.
Technically, this is not so much an insight as an intuition. It might
not be true in all cases. But using it as a heuristic, we can cut the
solution down to O(n^3).
The “split” function takes a list of values and the number of gang
members and returns a list of sublists that all sum to the same amount,
or nil if no solution is possible. It works by sorting the list of
values and calling “pick” once for each gang member to pick out that
member’s share from the remaining list. Using our insight, we never
backtrack in “split”. Once we’ve picked one member’s share, we never go
back to try a different combination.
“Pick” works recursively, walking from the high end of the list to the
low end, until it finds a sublist that sums to the target amount or it
runs off the end of the list. This function waits to delete elements
from the list until it finds a sublist that sums to the target amount.
In this way, “pick” doesn’t have to create any intermediate lists.
My submission is attached. The key insight: if you start with the
largest values you can divide the loot one gang member at a time without
fear of getting wrongly stuck.
…
Technically, this is not so much an insight as an intuition. It might
not be true in all cases. But using it as a heuristic, we can cut the
solution down to O(n^3).
I thought I had a similar speedy solution, but then I found a few
places it fails:
Try splitting [4, 6, 8, 9, 18, 26, 34, 36, 39, 40, 43, 50, 55, 66, 67,
76, 82, 83, 86, 91, 96] into 5 parts.
The top-down approach fails to find an even division, but it is
possible:
0: 82 66 55
1: 86 67 50
2: 91 76 36
3: 96 83 18 6
4: 43 40 39 34 26 9 8 4
I used the following to generate a bunch of test cases (not all of
which are solvable):
r = []
n=rand(8)+2
20.times{|e| r<< rand(100); }
r << n-r.sum%n i #make sure it’s divisible
p n,r
…
Technically, this is not so much an insight as an intuition. It might
not be true in all cases…
D’oh! Here’s my second solution, which does backtrack if necessary. It
handles Adam’s example, and a shorter example I found:
This one uses recursive yielding to manage the search space. It should
be close to the first solution in speed for cases where the heuristic
applies, except for the array duping.
My solution is attached. It solves via recursion with a few
optimizations (it is still really slow, though)
Here is an updated version that stops recursing, if someone gets
assigned more than his share. (I can not believe that I did not
think of this earlier) This speeds everything up quite a lot.