Re: [eclipse-clp-users] Propagators with a state

2009/2/18 Kish Shen <kisshen_at_cisco.com>:
>
> I don't think priorities are that bad, particularly when you are dealing
> with only one solver.
>
I am sure that there was a sensible reason for introducing priorities.
I can even see some of them but I lack running priority feature that was
mentioned by Joachim. With this feature I would find ECLiPSe very
good base for developing solvers for hard problems. Of course, this
is just behind having rich library of global constraints.

> One important property about priorities is that the execution of a goal
> can only be `interuppted' by woken goals that have a *higher* priority.
What is a reason for not having propagators? I cannot see it.

> Specifically, woken goals with the *same* priority does not interrupt
> the execution, because woken goals are placed at the end of the
> resolvent. So if you write your propagators at the same priority, they
> will be "atomic" with respect to the other propagators (at the same
> priority).
>
That is good property but unfortunately there are mostly woken goals
that are written by other parties.

> This is somewhat different from suspension/wake implemented in other
> Prologs, and which do not have priorities. Woken goals in this case
> effectively have a higher priority (they are added to the front of the
> resolvent) and will interupt your current execution. You don't really
> have the flexibility to control this.
>
But they do not interrupt propagator itself, don't they?

> The suspension mechanism (along with attributed variable) is designed to
> give you the ability to write code for different solvers in ECLiPSe (and
> not just propagators for say finite domain), and to allow these
> different solvers to co-operate. It also give you the full flexibility
> of the whole ECLiPSe language to do so.

> For example, I was recently involved in helping to add some domain consistent
> (generalised arc consistent) global finite domain (ic) constraints, which we plan to add
> to ECLiPSe 6.1.
Where could I find a road map for developing ECLiPSe? You and Joachim
have mentioned about features that should be available in 6.1 version.
What other features could we expect?

> These constraints are based on working on a flow graph.
What constraints are you talking about? There is quite a lot
of constraints that are based on flow graph.

> Everything was done in ECLiPSe for this, there was no need to go to a
> low-level language like C. In other systems, I suspect that you may very
If you can implement this in Prolog then I do not see necessity to use C
in SICStus or B-Prolog or SWI-Prolog.

I have used LP and CLP(FD) solvers for fast prototyping ATSP
solver. It worked really nice, few times faster then a pure (+ circuit
constraint) CLP solver. Finally I have implemented assignment problem
in C but only because I had a code at hand (speedup was next
few times). I have in plans to implement this in ECLiPSe, anyhow.

Best regards
-- 
[ Wit Jakuczun  w.jakuczun_at_wlogsolutions.com ]
[ WLOG Solutions http://wlogsolutions.com   ]