Inefficient packing

[dvdoug]

Not sure if I should open a separate task or not but here is a similar example that is actually much simpler:

• 5 units of an item which is 2.6 L x 2.6 W x 4.6 H inches
• One box option that is 7.25 L x 7.25 W x 6.5 H inches (a USPS flat rate box)

This should be able to fit up to 6 units by laying 4 on their side and stacking those 4 two high and then the remaining two upright. However, BoxPacker splits it into two boxes (first one with 3 units shown) but you can see how six would be able to fit:

Originally posted by @colinmollenhour in #264 (comment)

[colinmollenhour]

Hi @dvdoug what are the chances realistically of you being able to make optimizations to the algorithm to address problems such as this in 2022?

[dvdoug]

Hi @colinmollenhour

🤞 I should have time around October to come back and have a proper attempt at issues like this - unfortunately while it's easy(ish) to figure out which packing decision is being non-optimal in any given situation, it's usually the case (it is here) that tweaking things to make one packing scenario better tends to regress others - and sadly I haven't had the time recently for complicated issues, only simple ones.

Please rest assured though, this is not an abandoned lib

[colinmollenhour]

@dvdoug Thanks for the update. Let me know when you start if you need any assistance from my team with testing or otherwise.

[colinmollenhour]

Hi Doug, thanks for tackling and fixing this issue! Is it simply fixed, or does the usage need to be changed to take advantage of the changes to fix it? Do you have any further info on the logic behind the changes?

[dvdoug]

When released, it will be automatic - it will still only consider the allowed rotations (e.g. keep flat will be respected) but instead of simply running the heuristic to guess at the best orientation and then firmly sticking to it, if there are items that don't fit into the box, it will go back and retry starting with by placing that first item in each of the other orientations to see if a better result can be obtained

[dvdoug]

By restricting the try-everything version to just the first item, performance on the whole doesn't suffer - although there will be additional extra packings done inside the new loop (potentially 3x slower), this is more than offset by the extra packing efficiency meaning that the weight redistributor doesn't kick in as much (or at all when going from 2 to 1)

[colinmollenhour]

Thanks for the additional information, and your continued support of the project. Would you be interested in working part-time or full-time on our WMS development team? We recently received additional investment and are looking to add a lot of new features. It is mostly PHP and MySQL with a few other components. Thanks again, Colin

…

________________________________ From: Doug Wright ***@***.***> Sent: Sunday, March 17, 2024 4:37 PM To: dvdoug/BoxPacker ***@***.***> Cc: Colin Mollenhour ***@***.***>; Mention ***@***.***> Subject: Re: [dvdoug/BoxPacker] Inefficient packing (Issue #272) By restricting the try-everything version to just the first item, performance on the whole doesn't suffer - although there will be additional extra packings done inside the new loop (potentially 3x slower), this is more than offset by the extra packing efficiency meaning that the weight redistributor doesn't kick in as much (or at all when going from 2 to 1) — Reply to this email directly, view it on GitHub<#272 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAJOUVTU2COYH4Q3U3QKJ3YYX5KLAVCNFSM5MDA23TKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBQGI3DAOJXGQ2Q>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dvdoug]

Many thanks for that offer @colinmollenhour but happily employed currently so I'll need to decline