Unexpected behavior with simple arithmetical constraint (+Java)

[cprudhom]

Dear developers,

I encounter a strange result while calling ibex.contract(...) on the following example (in Java):

Ibex ibex = new Ibex(new double[]{1.e-1});                    
ibex.add_ctr("{0}>=1.");                                      
ibex.build();                              
double[] domains = new double[]{0.15, 85.0};                  
ibex.contract(0, domains);
out.printf("%s\n", Arrays.toString(domains));                 

This prints [1.0, 85.0] when domains = new double[]{0.15, 85.0};
But, when upper bound is greater or equal to 86.0 it prints [0.15, 86.0] (f-ex, domains = new double[]{0.15, 86.0};).

Any ideas how to fix this ?

Best,
CP

[gchabert]

Strange, indeed.Thanks for reporting. It will be fixed by tomorrow.

[gchabert]

Ok, I see.
When the upper bound is >=86, the contraction is less than 1% of the domain so it is ignored, and the return code is NOTHING.
Removing this threshold and returning CONTRACT is not a good option. You would fall into long contraction loops with very tiny reductions.
Returning NOTHING and keeping the domain contracted is worse as this would be an inconsistent behavior (error-prone on Choco side).
Maybe should I return NOT_SIGNIFICANT in the case of contraction < 1% (like for the inflation). And maybe this threshold could be setable from Java?
What do you think ?

[schmittjoaopedro]

Hello,

I'm interested in this issue because I've found the error on choco-solver. Could you explain how ibex developers work around this problem, I mean, no one deal with such interval reductions that not achieve 1% of significance? This is a common issue, if not, why not?

Thanks in advance,

[gchabert]

Hello,
This is not an issue because the branching process (would it be that of choco or ibex) ensures that the widths of intervals go to zero. And this is why, so far, we did not need to make a distinction between "no contraction at all" and "not a signification contraction".
However, the threshold of 1% is a bit coarse. In the ibex solver, we rather use a combination of absolute and relative threshold and people typically set both to 1e-3.

[cprudhom]

Hi,

I suppose that NOT_SIGNIFICANT will be a good answer, and that Choco can manage it.
Let me know when Ibex handles that.

Best

[schmittjoaopedro]

We are starting a important project using the choco-solver in the company. Would be nice if such feature could be released until the end next month.
For while, there is another way to define the relative threshold to 1e-3 that doesn't depends of choco?

Thanks,

[gchabert]

Sure, I can make the update quickly; it's a minor thing. I let you know.
PS: @schmittjoaopedro , would you mind signing the guest book of Ibex?

[gchabert]

Thinking again about this topic, I am not sure that we really need two different status for contraction: NOTHING and NOT_SIGNIFICANT. Would you distinguish both? If, say, a contraction only removes a single float in a domain, what difference would that make comparing to nothing removed at all?
My suggestion is to leave the return status as today and just to give the posiblity to set the threshold from java. Agreed?

[cprudhom]

Indeed, NOT_SIGNIFICANT is currently not used. NOTHING triggers no specific action, as expected. So I suppose the best option is to set the threshold programmatically.

[gchabert]

Ok, it's done in the 'develop' branch and it will be integrated in the next release. You can test meanwhile with 'develop'.
Now 'contract' requires an additional argument: the threshold as a relative ratio (see comments in ibex.java).

[cprudhom]

Is this published in 2.8.7 or still under development ?