Objective: Given a "container" size and a list of numbers,
return an array of array references ("containers")
which contain the supplied number list in groups of
for which the sum does notexceed the specified container
size. Further, the function should return only the
minimum number of containers required to solve the problem.

Any numbers which absolutely cannot be accomodated given
the input data and container size should be
returned "unbagged", that is, as scalar data trailing the
returned array references.

Other notes: Negative, zero, and fractional values are valid
input data for both the input list, and the container
size. As such, numbers larger than the container size cannot
be immediately discarded without first considering other input data.

I'm not even going to attempt to write any code for this
because it's pointless. For
positive numbers, the problem
is already NP-complete. When you mix in negative numbers,
it becomes worse. The only feasible way to proceed is to generate all
possible groupings and brute-force your way through them.

It is NP-complete, so there's no way a super-efficient 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.

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.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other