Skip to content

Enhanced Bin Packing propagator#202

Open
95A31 wants to merge 4 commits into
Gecode:mainfrom
95A31:release/6.3.0
Open

Enhanced Bin Packing propagator#202
95A31 wants to merge 4 commits into
Gecode:mainfrom
95A31:release/6.3.0

Conversation

@95A31

@95A31 95A31 commented Sep 15, 2024

Copy link
Copy Markdown

Hello,

This patch implements a stronger pruning technique for the BinPacking constraint. It leverages tighter lower bounds based on Dual-Feasible Functions. This approach was presented at CP 2024 in the paper CP for Bin Packing with Multi-Core and GPUs.

There might be a need for some polishing and testing, but I think the benefits are worth the effort. I attached a simple model for testing.

Cheers

bpp.mzn.txt
N2W1B2R5.dzn.txt

@zayenz zayenz changed the base branch from release/6.3.0 to main July 7, 2026 08:25
@zayenz zayenz force-pushed the release/6.3.0 branch 2 times, most recently from be6b80c to a883d63 Compare July 7, 2026 10:44

@zayenz zayenz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed 44fbbe3 to fix the definite integer-range defects in the DFF arithmetic: half-capacity comparisons, transformed-weight accumulation, RMax capacity arithmetic, and lambda-step overflow. The commit also adds boundary regressions. The focused BinPacking tests pass in Debug/Audit and UBSan builds, the CMake smoke suite passes, and the tree passes tidy.

I am leaving three algorithm and policy questions for manual review:

  1. The sampler drops both interval endpoints and every singleton interval. That differs from the inclusive ranges in the cited algorithm and weakens propagation in at least one small case: capacity 11, three bins, weights {7, 7, 5, 5, 5} fails at the root on main, but not on this branch.
  2. RMin currently duplicates R0 at this call site because the minimum virtual weight is always zero.
  3. The sequential portfolio has a substantial hot-path cost. On u120_00 it explored the same 94 nodes and ran the same 217 propagations, but took 47.99 ms versus 2.67 ms on main (five samples, 20 runs per sample, Release builds). The paper's implementation relies on parallel evaluation of the DFF portfolio.

I would keep the PR open until we decide whether the exact L2 check should be preserved alongside the sampled portfolio, and what performance gate this propagator should meet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants