[gecode-users] Unary and Cumulative constraints

[Guido Tack]

David Rijsman wrote:
> you are right, it should be 'implied reification' and yes it is unnecessary overhead to post e = p + s for each propagator but it would also give you some more control on scheduling or not scheduling the propagator on deltas on e,p or s.  Perhaps not much to gain. 

When you have hundreds of tasks, propagator scheduling might actually become important.  But I think I'll start with the simple version, and then see if there is a problem.

> I read you are working on a temporal propagator (STN?) and on a nice modeling API? Are you going to put this in the mini model part or are you building a complete new scheduling layer? Any pointers on what kind of construct are going to expose and if you are planning any new scheduling constraints?

There would be an STN-like propagator, which is exposed on the same level as the current scheduling constraints (i.e., variables and integers).  On top of that, in the minimodel layer, there would be abstractions for tasks, resources and the like.  I don't have plans to add any other scheduling constraints at the moment (anything in particular you'd be interested in?).

I haven't decided on the actual interface for the modeling layer yet.  It could be something like cumulative functions in ILOG CP Optimizer, or a more classical model with resources etc.

The current state is that I have an STN propagator for mandatory tasks with fixed durations, so I have to put some work into generalizing it for optional tasks and flexible durations.  The main thing that is currently missing are specialized branchings that order tasks on resources.  I'll build them on top of the STN, because they require information about the partial order of the tasks.

I can't say yet when these things will be available, though.

Cheers,
	Guido

-- 
Guido Tack, http://people.cs.kuleuven.be/~guido.tack/