in reply to (Golf) Grocery Bagging
I'm not even going to attempt to write any code for this
because it's pointless. For
positive numbers, the problem
is already NPcomplete. When you mix in negative numbers,
it becomes worse. The only feasible way to proceed is to generate all
possible groupings and bruteforce your way through them.
For three elements, it's easy: abc, ab c, ac b, bc a.
For four elements there is already an explosion of combinations:
abcd, abc d, abd c, acd b, bcd a, ab cd, ac db, ad cb,
ab c d, ac b d, ad b c, bc a d, bd a c, cd a b, a b c d.
I won't even post what the results of 5 gives, and I doubt
this server has enough disk space available to store all
the possible enumerations of 10 elements.
One could start to develop heuristics that paid special
attention to groups of elements whose sigma matches the
container size, but then that's going against the spirit
of golf.
Noodling around some code here, it looks like the
complexity of the algorithm is O(n!). Which means that it's
going to be quite... slow.
 g r i n d e r
Re^2: Golf: Grocery Bagging by tadman (Prior) on May 23, 2001 at 20:18 UTC 
It is NPcomplete, so there's no way a superefficient general
solution is going to emerge here. However, the evaluation of
any particular ordering doesn't require evaluating all possible
groupings of that ordering. You can merely start adding
stuff until an overflow occurs, switching to the next bag
as necessary. The "best" solution out of the possibilities
evaluated is the one that uses the least containers.
Perl is buff enough to spin through several million
possibilities in realistic time, unless you're using a
version of Perl for Palm Pilot. I would submit that as long
as a Perl Golf program runs in finite time (even extremely,
exponentially long), the point is to make a minimally sized
program that produces the correct solution.
 [reply] 

You can merely start adding stuff until an overflow occurs, switching to the next bag as necessary.
No, I thought that too, at first, but you've got the problem of having permitted
negative elements, so adding the next element might overflow, but the element
after that (if negative) might bring it back. Argh!
So while there might be a solution other than generating all possible partitions
and seeing which ones have acceptable weights, it's not along the line of "fill
until it won't fit". Sorry.
 Randal L. Schwartz, Perl hacker
 [reply] 

It might, but if you're going to evaluate all possibilities,
who cares? As in, if you are worried about a scenario such
as the following, where the 10 gets bagged "solo" despite
there being a 5 farther down the pipeline:
( [ 9 ], [ 10, 5], [ 11 ] )
Then later on you will inevitably evaluate a scenario where
the 5 is inserted earlier.
( [ 9, 5, 10 ], [11] )
So, taking the "brute force" approach, you might lose points
for style, but you get the job done, no?
Has anyone ever pointed out to a grocery checker that
the bagging problem was NPcomplete? The result might be
similar to explaining that dogs can solve quadratic equations
(i.e. capturing a frisbee in a parabolic arc while in linear
motion).
 [reply] [d/l] [select] 

