Repository navigation
Conversation
PropGccBC (bounds-consistency, Quimper et al. CP-2003) and PropGccAC
(arc-consistency, Regin AAAI-96) are posted alongside the existing
PropFastGCC, opt-in via GlobalCardinality(..., "BC"/"AC") or
model.globalCardinality(..., "BC"/"AC"). Both share a dense flow
network over the full [min, max] value range so that unrestricted
("escape") values are handled soundly.
Includes a fix for AlgoGccAC's augmenting-path search: after a warm
start where every variable is already matched, the search had no
genuinely free variable to end an augmenting path on, so a later
propagate() that raised several values' lower bounds at once could
wrongly report a value's minimum as unreachable even though a trivial
reassignment existed (found via fuzzing against a DEFAULT+search
ground truth, after testDeficitAppearingAfterWarmStart caught it on
real peaceable_queens instances under optimization). The search now
also accepts a variable sitting on a value with slack as a valid
endpoint, mirroring the existing donation-through-source mechanism.
Benchmarked across three independent campaigns (macpro, srv/Slurm ×2) on real FlatZinc instances: BC matches AC on solution quality while being algorithmically cheaper, and both markedly outperform the previous DEFAULT (PropFastGCC-only) on tightly-constrained instances -- sometimes by orders of magnitude in nodes explored. Every caller of the 4-arg globalCardinality(...)/GlobalCardinality(...) overload (no explicit consistency string) now gets BC. The choice is centralized in GlobalCardinality.defaultConsistency() and overridable via the choco.gcc.consistency system property, so it can be swapped for benchmarking without touching calling code.
Modeler.modelGCC_AC/modelGCC_BC mirror the existing modelAllDiffAC/modelAllDiffBC pattern: only the decision variables are exposed to ConsistencyChecker, since PropGccAC/PropGccBC only guarantee their consistency level on decision variables (cardinality variables are left to PropFastGCC's weaker bound reasoning, see PropGccAC's javadoc) -- testing cardinality domains the same way would flag intentional, documented behavior as a false failure. The restricted value set is fixed by the (call-invariant) variable count, never derived from the incoming domains' actual content, since the checker re-invokes the modeler with one variable narrowed to a single value at a time and the constraint being tested must stay the same constraint across those calls. TestConsistency gains testGCC_AC/testGCC_BC; TestCorrectness's existing testGCC() is extended to also check modelGCC_AC/modelGCC_BC against the decomposition.
Contributor
|
This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again. |
Member
Author
|
I forgot to adapt the stats for mzn and xcsp3 test suite. |
jgFages
approved these changes
Sep 29, 2026
Switching GlobalCardinality's default consistency to BC changes the search statistics (nodes/fails) of the test instances relying on GCC. Solution counts and best values are unchanged.
ArthurGodet
reviewed
Sep 30, 2026
ArthurGodet
left a comment
ArthurGodet
left a comment
Collaborator
There was a problem hiding this comment.
It is not necessary and I woul dunderstand if it stays the same as currently, but since PropGccAc and PropGccBc share most of their code, it might be interesting to factorise their code into a PropGcc class.
Both propagators shared an identical propagate() (dense minOcc/maxOcc construction), a near-identical constructor, isEntailed() and toString(); the only real differences were the PropagatorPriority, the filtering algorithm, and the propagation conditions. Introduce a GccFilter interface implemented by AlgoGccBC/AlgoGccAC, and collapse the two propagators into one PropGcc class parameterized by GlobalCardinality.Consistency (BC/AC), which now decides the priority, the algorithm, and getPropagationConditions from that single field.
Member
Author
|
GCC review follow-up (post- Since merging
No correctness issues remain open. The only unresolved item is a pure allocation-reuse question (reusing |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Porting of the Global Cardinality BC and AC filtering algorithms from choco-1.2.0.6.
The primary aim was educational, for the purposes of a Constraint Programming course on consistency.
Just to be on the safe side, I ran the tests on MZN instances (default, BC and AC) and, as the BC results are satisfactory, I propose that this configuration be set as the default.
Scatter plots
Cactus plots
Gains and losses