radsz/jacop

XneqC constraints are dropped silently

Closed this issue · 3 comments

JaCoP 4.6.0

When an XneqC constraint is imposed on an IntVar with a BoundDomain, it can happen that the constraint is ignored and dropped, i.e. not considered in later consistency checks. This does not happen right away, but on the first consistency check.

Observed behaviour
Consider an IntVar x with a BoundDomain in {-500; 500}. Now impose XneqC(x, 0). The first check of consistency brings us here

@Override public void consistency(final Store store) {
x.domain.inComplement(store.level, x, c);

which delegates to

@Override public void inComplement(int storeLevel, Var var, int complement) {
if (this.max == this.min && this.max == complement)
throw failException;
// Can not be removed without changing the code below.
if (complement != this.min && complement != this.max)
return;

which disregards the complement and just leaves the domain unchanged; but to make things worse, the XneqC is also never considered on later changes to X. It seems that the constraint is dropped.

Expected behaviour
Modify the BoundDomain, or keep consulting the constraint when changes to the domain of X are made later. If all else fails, give a clear indication (runtime exception?) about the fact that this operation has failed.

Workaround
Use an IntervalDomain instead of the BoundDomain – this circumvents the described problem, but I am not sure about the effect on other operations...

radsz commented

Thank you for raising this issue. BoundDomain is something that was of an experimental nature and we use it very rarely. For a moment, the best approach is not to use this domain. Similar issue may be for other very simple constraints like In, etc. We need to think what to do with this domain type. I would not be suprised if it is removed. Therefore, I advise not to use it.

Oh, that is good to know. What domain type would you suggest to use as an alternative?

krzku commented

Class BoundDomain is non-public and it cannot be used outside JaCoP package.