-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Box dimension order affects volume utilization #275
Comments
The documentation has the following to say:
I'm going to use rsort() to work around this problem for now. Let me know if you think this makes sense. SOURCE
|
When initially packing a box, BoxPacker will consider both orientations of the box, and the order you specify doesn't matter. However after that phase, by default BoxPacker activates its weight-redistribution mode (https://boxpacker.io/en/stable/weight-distribution.html) which by-design trades away optimum packing efficiency for the goal of balancing weight. Because of that, the "try both versions of width/length" behaviour is not used here. In the vast, vast majority of cases I've seen the ordering doesn't matter at all although obviously here you've found one that does. It's important to note though, that in other cases the opposite ordering would indeed be best (i.e. for other cases, rsort would give you worse efficiency than sort). If optimum packing efficiency is your goal, then you can disable weight redistribution (see the link), then both versions will give the same results. |
Hi Dough. First of all: thank you for your amazing work!!! Here the same issue, I think, but not solved by balance weight deactivation. The example I bring, is very similar, I think: if I pass an item with two interchanged measures, the result is different: packer adds a second box or not, regardless of whether I tell it that the items can be rotated or not. The products are: And the Europallet, measures: 120x80x215 This case is very demanding, since the items, in a specific orientation, can perfectly use the volume of a pallet, being distributed in 5 layers of 4 items each, one of 39cm high, one of 47, two of 33, and one with mixed heights which therefore occupies the maximum: 47 as well. The sum of the heights is: 39 + 47 + 33 + 33 + 33+ 47 = 199 Thanks, Here the modified code for this example:
|
@CarlesRever yours is slightly different, this one is about the dimensional order of the boxes, yours seems to be about the dimensional order of the items - specifically for your particular set the library is guessing at the wrong "best" one when its allowed to rotate. But I'll add it to my list of non-optimal solutions to investigate |
Thanks for your work!!! |
The following test case demonstrates that if I swap the length and width in the box dimensions, the utilization changes from 65.3% to 56.6%. In the first test, the box is able to accommodate 4 items. In the second test, it can accommodate only 3. I would not have expected the order of the dimensions to have any impact on the utilization.
In this example, I swap the length and width between addBoxes1 and addBoxes1 to demonstrate the issue.
Is there something I should do to ensure that I get the maximum utilization? Perhaps I should ensure that the dimensions are specified with the largest ones first?
SOURCE
OUTPUT
The text was updated successfully, but these errors were encountered: