[gecode-users] Propagation order

Peter Vanhee peter.vanhee at gmail.com
Mon Jun 14 10:57:52 CEST 2010


Thanks, that does help. 

I don't rely on running C before D, i.e. all constraints are independently.

Runtime will increase if I run C before D however, and anyways, if
C fails, there is no need to run D.

I'll rely on the unary, binary etc order of the current implementation.

Bye,
Peter

On 14 Jun 2010, at 10:53, Christian Schulte wrote:

> Well,
> 
> You are right that A and B will go before C and C before D but this is just
> in the current implementation. We might change the implementation in the
> future, though. The reason why we just approximate the cost values is that
> each cost value takes memory.
> 
> So, the idea is: very often the cost is respected by the system. But what
> you can't do is: you implement D such that it breaks if C has not run
> before.
> 
> Does that help?
> 
> --
> Christian Schulte, www.ict.kth.se/~cschulte/
> 
> 
> -----Original Message-----
> From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
> Of Peter Vanhee
> Sent: Monday, June 14, 2010 10:39 AM
> To: users at gecode.org
> Subject: Re: [gecode-users] Propagation order
> 
> Hi Christian,
> 
> Most of the propagators I have implemented behave like filters: they get at
> least one assigned variable and then accept or discard the assignment.
> 
> Some constraints are much more heavy than others and therefore I'd have 
> them run after the less heavy constraints. 
> 
> For example
> 
> A -> PropCost::binary(PropCost::LO);
> B -> PropCost::ternary(PropCost::LO);
> C ->PropCost::quadratic(PropCost::LO);
> D -> PropCost::crazy(PropCost::HI);
> 
> Can I rely on the fact that always A goes before B, B before D and so on?
> It seemed to me that D would be run before all the rest, but that between A,
> B and C there was not always a clear order.
> 
> Bye,
> Peter
> 
> 
> On 14 Jun 2010, at 10:18, Christian Schulte wrote:
> 
>> Hi,
>> 
>> There are of course the normal cost values: unary, binary, ternary,
> linear,
>> etc. The system picks the cheapest, however some cost values are treated
>> alike. That is why there are no hard facts to be relied on.
>> 
>> But maybe you can give us an idea what you try to achieve?
>> 
>> Cheers
>> Christian
>> 
>> --
>> Christian Schulte, www.ict.kth.se/~cschulte/
>> 
>> 
>> -----Original Message-----
>> From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
>> Of Peter Vanhee
>> Sent: Monday, June 14, 2010 7:23 AM
>> To: users at gecode.org
>> Subject: [gecode-users] Propagation order
>> 
>> Hi all,
>> 
>> I am trying to weight different propagators implementing a cost function
>> "virtual PropCost cost(const Space&, const ModEventDelta&) const".
>> 
>> As indicated by the documentation "The only hard fact you can rely on is
>> that a propagator 
>> with a cost value using PropCost::HI is never given preference over a
>> propagator with a cost 
>> value using PropCost::LO". 
>> 
>> For my particular problem however I'd need to weigh propagators quite
>> differently,
>> so they get executed almost sequentially, and simply saying LO or HI isn't
>> enough. 
>> Does gecode offer another way to control the order of propagation?
>> 
>> Thanks,
>> Peter 
>> _______________________________________________
>> Gecode users mailing list
>> users at gecode.org
>> https://www.gecode.org/mailman/listinfo/gecode-users
>> 
> 
> 
> _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users
> 




More information about the users mailing list