It's chosing the smallest bins rather then choosing fewer bins.

[rprophett]

Your API is great. I'm glad you guys made it. But I have one problem. The algorithm always chooses the smallest bins provided. So, when I provide it 10 type A bins that fit 6 items, 10 type B bins that fit 12 items and 24 items it puts those items in 4 type A bins when they could fit in 2 type B bins.

See http://pumptechnicalbooks.com/packaging_estimator_packit4me.html

I created this to test out your api. You can see that 8 items provided in that script should fit in 1 box but the api recommends using 2 boxes. I set it up so that if you check the javascript console you can see the exact bins and items lists fed to your api.

This essentially forces me to provide your api only one type of bin (or box), the largest box type I have, in order to minimize the number of boxes returned.

[EmanH]

I've got the same problem. It should by preference pack everything in one larger box, rather than splitting into smaller boxes by default. Postage wise it's cheaper sending one larger box, rather than two smaller boxes. Is this API still being developed?

[asharif]

You are right. The algorithm as it stands simply sorts the bins and tries to pack from smallest to biggest. It's a bit greety like that. You could argue it's not an algorithm but a greety heuristic really. I can perhaps add another layer to make it smarter with attempting to bin in one box.

[EmanH]

It would be fantastic if you could do that.

[siraz-dev]

@EmanH Do you know logic about how to get x_origin_in_bin ,y_origin_in_bin and z_origin_in_bin?