Could this be a bug?

[Hao]

Came across this case, somehow the propagation stopped when it shouldn't

Before consistency check

*** Store
oneHundred = 100
minusOneHundred = -100
Node11::{-100..100}
Node13::{-100..100}
sum11::{-10000..10000}
sum11Over100::{-100..100}
min11CompareTo100::{-100..100}

*** Constraints for evaluation:
XmulCeqZ22 : XmulCeqZ(sum11Over100::{-100..100}, 100, sum11::{-10000..10000} )
XeqC19 : XeqC(Node13::{-100..100}, -50 )
XmulCeqZ21 : XmulCeqZ(Node13::{-100..100}, 25, sum11::{-10000..10000} )]
Max16 : max( minusOneHundred = -100, min11CompareTo100::{-100..100})
Min18 : min( oneHundred = 100, sum11Over100::{-100..100})]

After consistency check

*** Store
oneHundred = 100
minusOneHundred = -100
Node11::{-100..100}
Node13 = -50
sum11 = -1250
sum11Over100::{-100..100}
min11CompareTo100::{-100..100}

*** Constraints for evaluation:
Max16 : max( minusOneHundred = -100, min11CompareTo100::{-100..100})
Min18 : min( oneHundred = 100, sum11Over100::{-100..100})]

any comments?

[kris]

Hi!

I have one possible reason why consistency has stopped.The problem is inconsistent and when the solver discovered inconsistency it stopped evaluation. Did you check the result of method store.consistency()? If it returns false it means that your problem is inconsistent and has no solution.

Moreover, your min and max constraints look strange.They should have as arguments a list of variables and a variable. In the print-out they have two variables. It might be JaCoP bug but check this as well.

/Kris

[kris]

Hi again!

I have found your problem. Constraints

XmulCeqZ22 : XmulCeqZ(sum11Over100::{-100..100}, 100, sum11::{-10000..10000} )
XmulCeqZ21 : XmulCeqZ(Node13::{-100..100}, 25, sum11::{-10000..10000} )

are inconsistent Node13 = -50 and sum11=-1250 and in the first constraint you try to multiply value by 100 that will never be -1250.

/Kris

[Radoslaw Szymanek]

Hi,

In the newest version (development version, downloadable from sourceforge svn repository) the printouts for Min and Max are fixed.

You can download the development version from SourceForge and check if the problem persists.

XmulCeqZ is inconsistent as Kris pointed out, but I am not sure how did Node13 got value -50. Was it due to buggy constraint (XmulCeqZ) or some external factor not included in printouts like calling function that restricts value of Node13?

If the result of store.consistency() is false then store is in inconsistent state and any printouts should be ignored as they are just printouts of inconsistent state of the store.

For a moment, I am wondering why Node13 got value -50.

If you send me a small program that exhibits the behavior you have shown then I will be able to do some tests and search for explanation for you.

best,
Radek

[Radoslaw Szymanek]

Hi,

An update.

I was blind and I did not see that you have a constraint XeqC(Node13, -50).

Your model is simply inconsistent and there is no solution. Therefore, printout after consistency check that has returned false just shows the state of the store at which the inconsistency has been discovered.

You need to fix your model to allow a solution.

best,
Radek

[Hao]

Hi again! I have found your problem. Constraints XmulCeqZ22 : XmulCeqZ(sum11Over100::{-100..100}, 100, sum11::{-10000..10000} ) XmulCeqZ21 : XmulCeqZ(Node13::{-100..100}, 25, sum11::{-10000..10000} ) are inconsistent Node13 = -50 and sum11=-1250 and in the first constraint you try to multiply value by 100 that will never be -1250. /Kris

I see that
Node13 = -50  => sum11 = -1250 => sum11Over100 = -12.5
so shouldn't we have sum11Over100 be either 12 or 13 here ?

Could you elaborate a bit more here as why is it inconsistent?

Thanks

[Hao]

Ok, I found my problem.

Node13 = -50 => sum11 = -1250 => sum11Over100 = -12.5 which is not an integer that stopped the propagation.

I'm including my solution here for other people who might face the same situations.

Basically I used to intermediate variables, quotientTimes100 and remainder, added two other constraints

sum11 mod 100 = remainder

quotientTimes100 + remainder = sum11

then instead of doing sum11Over100 * 100 = sum11, I did sum11Over100 * 100 = quotientTimes100

lost a bit of precision (which is not a big deal in my model) but got the job done.

Thanks you all for the input.

[kris]

Actually, for your problem you might use constraint XdivYeqZ, i.e. X div Y = Z. This is integer division with reminder. In you case you will use as sum11 div 100 = sum11Over100. You might try this.

[Hao]

Actually I was using XdivYeqZ but I was told to use multiplication for performance reasons.

Thanks you Kris.