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

Wit Jakuczun wrote:
> 2009/2/16 Kish Shen <kisshen_at_...5...>:
>> Wit Jakuczun wrote:
>>
>>> But I would love to have other features:
>>> - initial call of a propagator (could result in suspending). This would be
>>>  especially useful for propagators based on demons.
>> As propagators are normal ECLiPSe goals, you can simply write your
>> propagator such that it is executed once before suspension, something like:
>>
>> propagator(...) :-
>>        do_propagation(....),
>>        suspend(do_propagation(....)...).
>>
> 
> The code looks like that:
> 
> propagator(Vars, state(State0)) :-
>     update_state(Vars, State0, State1),
>     ( ground(Vars) -> check_solution(Vars)
>     ; do_propagate(Vars, State1),
>       suspend(propagator(Vars, state(State1), Susp), 3, Vars->inst, Susp)).
> 
> propagator(Vars, State,  Susp) :-
>     State = state(State0),
>     update_state(Vars, State0, State1),
>     ( ground(Vars) -> kill_suspension(Susp), check_solution(Vars)
>     ; do_propagate(Vars, State1), setarg(1, State, State1)).
> 
> update_state/3 must be called as there can be more that
> one variable instantiated comparing to previous call of a propagator.
> This is due to priorities!
> Now, propagator/2 is called and if there is a need for suspension
> a propagator/3 (demon) is suspended. If there were guarantee
> that propagators are called for each variable change separately
> then I could do as you proposed.
> I hope I clarified the issue.
> 
> Best regards
Hi Wit,

You can avoid writing two versions of propagator by checking if there
is a suspension in the propagator/3 code, e.g.:

propagator(Vars, State) :-
	propagator(Vars, State, _Susp).

propagator(Vars, State, Susp) :-
	State = state(State0),
	update_state(Vars, State0, State1),
	( ground(Vars) ->
		( is_suspension(Susp) -> kill_suspension(Susp) ; true ),
		check_solution(Vars)
	;
		do_propagate(Vars, State1),
		(is_suspension(Susp) ->
			true
		;
			suspend(propagator(Vars, ....)
		)
	).

On a more general point, if I understood you correctly, you are doing 
the update_state/3 in propagator/2 in your original code because the
state can change between calling propagator/2 and executing the goals
in propagator/2, because other propagators can wake up and update the 
State. If this is your concern, then I am not sure if your code would 
avoid the problem, because the update can happen after you do the
update_state/3.

To avoid this problem, you should use call_priority/2 to call
propagator/2 with a higher priority than what you are suspending your
propagators at -- so 2 in your case. In this case, you can also
miss out the initial update_state, and simplify the code a little.

Cheers,

Kish
	
-- 
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.