Class IloPoolOperator

Pool operators are ILOG Solver related entities which take an input in the form of a solution pool and instantiate Solver's constrained variables to create a solution therein. Importantly, operators can be cast to processors (IloPoolProc). This cast operator results in a processor which will transform the so-instantiated solver into an instance of IloSolution, based on a given solution prototype.

You can define custom operators by using the ILOIIMOP0 macro (or a variant). Numerous built-in operators are also provided, easily accessible from IloEAOperatorFactory.

For the most part, pool operators can be thought of as standard Solver goals with the additional property that they have access to an input pool of solutions which they use to influence their behavior.

This constructor creates an operator from a goal. When the created operator is executed, it will behave exactly as goal. Most often this constructor is useful when an operator needs to be combined with a goal using goal && op or op && goal. The constructor makes sure that a goal can be cast to an operator so that the && operator on pool operators can then be applied.

This member function adds a listener to the operator. Depending on the type of listener added to the operator, based on either IloPoolOperator::InvocationEvent or IloPoolOperator::SuccessEvent, the listener will be activated when the operator is invoked, or when the operator participates in the production of a solution.

This function deletes the object from the environment on which it was allocated and sets the implementation pointer to zero.

This member function returns the display name of the operator, which is useful for display purposes when type information is required on the operator. The name returned will be based on the function of the operator.

This function returns the environment on which the invoking object was allocated.

This member function returns a character string specifying the name of the invoking object (if there is one).

This member function returns the object associated with the invoking object (if there is one). Normally, an associated object contains user data pertinent to the invoking object.

This member function returns the solution prototype set in the previous call to IloPoolOperator::setPrototype or an empty handle if none was set.

This operator casts a pool operator to a pool processor. Objects of type IloPoolOperator can do very little work on their own; it is only in casting one to a processor that more useful work can be done with it.

When the cast operator is invoked, a pool processor is created which performs the following when invoked:

• Asks for input and supplies it to the operator.
• Invokes the operator.
• Searches for a solution prototype, either in the operator, or, failing this, in the input pool of the processor.
• Clones the prototype, saves it, and adds it to the output pool of the processor.

The resulting pool processor can be used with selectors and other processors via >> to create chains.

This operator specifies the number of solutions to produce, which will be at least size solutions. The code op(n) is shorthand for IloPoolProc(op)(n) where op is of type IloPoolOperator and n is an integer.

This member function removes a previously added listener from an operator. After the removal, listener will no longer be called when the operator is invoked or succeeds.

This member function assigns name to the invoking object.

This member function associates obj with the invoking object. The member function getObject accesses this associated object afterward. Normally, obj contains user data pertinent to the invoking object.

This member function sets the solution prototype. It indicates to an operator how the solution produced in constrained variables should be saved. When a solution needs to be created, the prototype is cloned and the Solver variables specified in the clone are saved using the IloSolution::store.

Setting the prototype in this manner is not normally necessary, unless quite specialized behavior is required for a particular operator. Normally, the prototype can be set more simply on an operator factory, ensuring that all operators produced by the factory will have the correct prototype. Even if this is not done, a prototype can be found by examination of the input pool of the processor which calls the operator.