Re: [eclipse-users] Finding which constraints failed

Vivek Balaraman wrote:
> Kish,
>  
> I am not trying to identify 'wrong' constraints but to know at runtime 
> which variable values have narrowed to null and at what point so that 
> users can refine values to get successful solutions. So apart from 
> watching constraints, I am also trying to watch variable domains.
Backtracking means that if labelling a variable to a value fails, it 
would backtrack and try and label differently. If you use labeling, this 
all happens automatically, but you can write your own code to both 
select the variable to label and the value (out of its domain) to label 
the variable to.

For even quite small constraint programs, it is impractical for the user 
to monitor this closely, and the labeling happens many many times.

You can use the visualisation tools to give you some feel of what is 
happening. Basically you can display the variables and their domains in 
different (including graphical) ways, and you can position the variables 
in different ways. This display will change as you execute your code. 
This gives an overview of what is happening, and may give you some idea 
on how to improve it.. See the Visulisation Tools manual to see how to 
use this. You can also use the display matrix, which is an older tool, 
and is much less flexible (variables arranges in a matrix only, and only 
textual representation of variables and their attributes), but which 
slows the running of your program down less.

If you are debugging your code, and you need to keep track of the 
attribute (e.g. the domain) of variables in a term (e..g. just the 
variable itself, or a constraint with several variables), you can use 
the `observe term' feature of the tkeclipse tracer, which uses the 
display matrix to pop up a window showing the term you selected, and any 
changes in the variables of the term can then be tracked. (you can 
observe the whole goal at a tracer port by right-clicking on the goal in 
the call stack and selecting `observe this goal'; you can select a term 
in the goal to observe by using the inspector to navigate to the term 
and then selecting it for observation.
>  
> I (perhaps mistakenly) tried using the 3 argument domain constraint 
> form $::/3 where I check the third Boolean flag to see when it becomes 
> 0. For example, $::(A,20..30,Bool) but this gives the domain of A not 
> as 20..30 but as -inf..inf and thus labeling tries to find values in 
> this expanded domain leading to an explosion of solutions.
>  
If you post a reified constraint with Bool uninstantiated, it behaves 
passively and  will only check if any changes are compatible with the 
reified constraint. In your case, if the interval of A is changed (say 
by some other constraint), your reified constraint will wake up to check 
if that is compatible with 20..30 -- if the new interval is a subrange 
of 20..30, Bool is set to 1; if the new interval does not overlap with 
20..30, Bool is set to 0. Otherwise it remains uninstantiated.
> Simply put,
>  
> How can I find out when the variable value becomes empty?
>
> I see that suspend provides me with some primitives such as 
> Vars->inst, bound, etc. Is this the way to go?
>  
I hope what I said previously answer your questions here -- you don't 
need to find out the interval have become empty, The system 
automatically backtracks to allow you to label the variables differently 
(and the incompatible values would be removed).

I note that you use $:: in your example -- you should use this if you 
really want real intervals only. If you want finite integer domains 
(which allows holes in the domain, real intervals don't), you should use 
the variants of constraints that starts with '#'. You get a lot more 
propagation (and fewer values to label)..

Cheers,

Kish
> Thanks 
>  
> On 8/31/07, *Kish Shen* <kisshen_at_cisco.com <mailto:kisshen_at_cisco.com>> 
> wrote:
>
>     Vivek Balaraman wrote:
>     > I have about 30 constraints in my system and about 40-50 parameters.
>     >
>     > I'd like to identify which constraint failed for a certain set of
>     > parameters both for debugging purposes and to inform the user
>     >
>     > What are the better ways of doing this?
>     >
>     > Thanks in advance
>     >
>     > Vivek
>     >
>     >
>     Since nobody else have replied to you, I will give it a try...
>
>     In most applications, posting the constraints will not normally be
>     sufficient to cause a failure, or to give you a solution to your
>     problem. You need to do some search (i.e. labelling the variables) to
>     get a solution (or failure). In this case, it is very hard to tell
>     which
>     contraint `failed' if you get a failure, because this will be the
>     result
>     of propagation, where generally a lot of propagators are woken and do
>     their propagation until eventually the domain of a variable is reduced
>     to empty.
>
>     If you are trying to catch only the failures while you are posting
>     the
>     constraints, then what you do is fine.
>     However, the failure here simply means that the constraint posted is
>     inconsistent with the constraints you already have, it does not
>     mean it
>     is `wrong', even assuming you know that your problem should have a
>     solution -- it could be some of your already posted constraints
>     that are
>     `wrong'.
>
>     Cheers,
>
>     Kish
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ECLiPSe-Users mailing list
> ECLiPSe-Users_at_crosscoreop.com
> http://www.crosscoreop.com/mailman/options/eclipse-users
>