Hi Guido, would it make more sense to always propagate when mandatory argument is not part of the argument list. When we allow a task not to be mandatory only enforce s = p + e when mandatory becomes true and make mandatory false when s = p + e can no longer be enforced (reify s = p + e on mandatory)?
This way we can model a task which can require one or more resources using the sum of the mandatory variables for the different constraints as the minimum and maximum constraints without having to worry about the temporal constraints within a task? David >>> From: Guido Tack <[email protected]> To: David Rijsman <[email protected]> CC: <[email protected]> Date: 8/10/2010 11:07 AM Subject: Re: [gecode-users] Unary and Cumulative constraints David Rijsman wrote: > Hi, > > First of all compliments for another very nice version. I am looking at the > new scheduling constraints introduced in version 4.3.0, and I trying to > understand why you have decided the following for some of the new cumulative > and unary constraints: > > "The propagator does not enforce s = p + e, this constraint has to be posted > in addition to ensure consistency of the task bounds." > > I can not figure out what a use case would be where you do not want s = p + e > enforced. If there are use cases why is it enforced in some of the > constraints? The reason is that you can have the same task on several resources at once, which would cause an overhead if each resource constraint in addition propagated s=p+e. Currently, the interface is a bit inconsistent, as the cumulatives constraint does propagate s=p+e. We plan to add modeling support for scheduling constraints in the future (I'm working on it), where you would declare task variables that encapsulate the s=p+e propagation. In fact, there would be one propagator for all the simple temporal constraints (such as task A is before task B, which translates to e(A) <= s(B) ), which gives strictly stronger propagation than the individual constraints. The resource constraints can then be posted in terms of these task variables. Cheers, Guido -- Guido Tack, http://people.cs.kuleuven.be/~guido.tack/ _______________________________________________ Gecode users mailing list [email protected] https://www.gecode.org/mailman/listinfo/gecode-users
