Class IlcConstraintI

A constraint is an object in CP Optimizer. Like other entities in CP Optimizer, a constraint is implemented by means of two classes: a handle class and an implementation class. In other words, an instance of the class IlcConstraint (a handle) contains a data member (the handle pointer) that points to an instance of the class IlcConstraintI (its implementation object).

Two member functions in this class actually implement the semantics of a constraint: isViolated and propagate. When you are defining a new class of constraint, you must define the member function propagate. That member function defines how the domain of a constrained variable must be reduced by the constraint. (Defining isViolated is not usually mandatory. Its definition is mandatory if you want to use the new class of constraint as a metaconstraint, for example in a Boolean formula.)

A constraint must be stored when it is posted so that it can be used by the propagation algorithm later. The member function post must be defined for that purpose. In other words, if you are defining a new class of constraint, when you define the implementation class for it, you must define this post member function as well.

A constraint can be used in a Boolean formula. In other words, you can combine constraints by means of the usual Boolean operators to produce other constraints. In order to use a constraint in that way, if you are defining a new class of constraints, then you must define the member functions metaPostDemon, makeOpposite, and isViolated.

For more information, see the concepts Propagation in CP Optimizer and Propagation events in CP Optimizer.

This constructor creates a constraint implementation. This constructor should not be called directly because this is an abstract class. This constructor is to be called in the constructors of subclasses.

By default, this virtual member function puts the name of the invoking constraint (if it has a name) on the output stream indicated by its argument; if the invoking constraint has no name, this virtual member function puts the string IlcConstraintI on that stream. When you define a new class of constraint, of course, you can redefine this behavior.

This member function causes the invoking constraint to fail at the choice point indicated by label.

This virtual member function is overloaded from IlcDemon to return IloTrue.

If this member function returns IlcTrue, the invoking constraint cannot be satisfied. This member function may return IlcFalse even if the constraint can not be satisfied. However, it should never return IlcTrue if there is a possibility of satisfying the constraint. This provision is made for cases where it can be computationally expensive to determine whether the constraint can be satisfied or not; in such a case, the function should return IlcFalse. Consistent with this remark, the default behavior defined in the class IlcConstraintI for this member function is to return IlcFalse.

Since this virtual member function implements part of the semantics of an invoking constraint, it is not mandatory to redefine it in all cases when you define a new class of constraint. It is mandatory if you want to use instances of the new class in Boolean expressions, as explained about logical Boolean operators for the class IlcConstraint.

The negation of a constraint is also a constraint. Semantically, this virtual member function expresses that principle. It is called to create the negation of the invoking constraint. This virtual member function must be defined when you define a new class of constraint if you want to use instances of the constraint in Boolean expressions, as explained about logical Boolean operators for the class IlcConstraint.

When a Boolean expression is posted on constraints, the expression has to be examined whenever the truth value of one of the constraints appearing in it changes. That is, a constraint is posted on the constraints appearing in the expression. Since it is a constraint on constraints, we call it a metaconstraint. The virtual member function metaPostDemon must be defined when you are defining a new class of constraints if you plan to use instances of the new class in Boolean expressions, as explained about logical Boolean operators for the class IlcConstraint.

This virtual member function is called to post its argument, a metaconstraint, on the invoking constraint. The metaconstraint should be associated with all the propagation events of the expressions appearing in the invoking constraint that may result in the unsatisfiability of the invoking constraint. Normally, these propagation events are the same events that are used in the post member function.

Thus the implementation of metaPostDemon is very similar to the implementation of post. The main difference is that metaPostDemon associates propagation events with the demon passed as an argument, whereas post associates propagation events with the invoking constraint.

This member function must associate the invoking constraint with propagation events triggered by the variables that it is constraining. This association is carried out by the member functions whenValue, whenDomain, whenRange (member functions of the classes IlcIntVar, IlcFloatVar, etc.).

We strongly recommend that you do not modify variables in the scope of this member function. In other words, you should not call a modifier on a constrained variable within your definition of this virtual member function.

This pure virtual member function must be redefined when you define a new class of constraints. It defines how the domains of constrained variables must be reduced by the invoking constraint. It is called by the initial constraint propagation algorithm in order to execute the propagation of the invoking constraint. This member function should reduce the domains of the constrained variables involved in the invoking constraint by removing the values that cannot satisfy the invoking constraint.

You should not call IlcCPEngine::solve from inside the member function * IlcConstraintI::propagate.

This member function pushes the invoking constraint onto the constraint queue. After pushing a constraint, the IlcConstraintI::propagate method of the invoking constraint will be called during the current round of constraint propagation.