For many applications, the facilities presented so far should be appropriate for using Simplex/MIP through ECLiPSe. However, sometimes it may be more convenient or efficient to directly access the solver state instead of going through the abstraction of the eplex instances. This section describes lower level operations like how to set up solvers manually. In fact, these lower level predicates are used to implement the predicates provided with eplex instances.
These predicates accesses the external solver state via a handle, which is returned when the solver state is set up, and subsequently used to access a particular solver state by the other predicates. The handle should be treated as a opaque data structure that is used by the eplex library to refer to a particular solver state.
This is used to set up a demon solver, and eplex_solver_setup/5 calls this predicate. There is one extra argument compared to eplex_solver_setup/5: the solver state handle Handle, which is returned by this predicate when the new solver state is created. The other arguments are the same as in eplex_solver_setup/5, except that there is an additional option in ListOfOptions: collect_from/1. This is used to specify which, if any, eplex instance the solver state should be collecting constraints from. If an eplex instance is specified (as pool(Instance)), then the solver state is associated with that instance. If the eplex instance is not to be associated with an eplex instance, none should be given as the argument to collect_from. This allows a solver state to be set up without the overhead of an eplex instance. The solver state will not collect any constraints automatically when it is invoked; instead the constraints must be added explicitly via the handle (using lp_add_constraints/3).
By default, the external solver is invoked once after set up by lp_demon_setup, if any TriggerModes is specified. Otherwise, the solver is not invoked and the predicate returns after set up.
This is an even lower-level primitive, setting up a solver state without any automatic triggering. It creates a new solver state for the set of constraints NormConstraints (see below for how to obtain a set of normalised constraints). Apart from the explicitly listed constraints, the variable's ranges will be taken into account as the variable bounds for the simplex algorithm. Undeclared variables are implicitly declared as reals/1.
However, when variables have been declared integers (using ::/2 or range:integers/1 or ic:integers/1), that is not taken into account by the solver by default. This means that the solver will only work on the relaxed problem (ie. ignoring the integrality constraints), unless specified otherwise in the options. Objective is either min(Expr) or max(Expr) where Expr is a linear (or quadratic) expression. ListOfOptions is a list of solver options, the same as for lp_demon_setup/6 and eplex_solver_setup/5, except for the collect_from and initial_solve options, which are specific for the demon solvers.
Constraints can be added directly to a solver state without posting them to an eplex instance. This is done by:
Add new constraints (with possibly new variables) to the solver state represented by Handle The new constraints will be taken into account the next time the solver is run. The constraints will be removed on backtracking.
The constraints are first normalised, and simple constraints filtered out (as discussed in section 11.3.1) before they are added to the external solver (by calling lp_add/3 described below).
This adds the constraints (both linear and intergrality) to the external solver represented by Handle. The linear arithmetic constraints must be normalised. Note that it is possible to add trivial constraints, which would be filtered out by the higher level lp_add_constraints/3 using this predicate. Integrality constraints on non-problem variables are filtered out and a warning given.
When a solver is triggered repeatedly, each invocation will automatically take into account the current variable bounds. The set of constraints considered by the solver is the one given when the solver was created plus any new constraints that were added (lp_add_constraints/3) in the meantime.
If there was an error condition, or limits were exceeded, lp_solve/2 raises an event. See section 11.10 for details.
In section 11.5.1, we discussed how solver state information can be accessed via the eplex instance. Here are the lower level predicates that directly access this information via the solver state's handle:
For example, it is possible to obtain the solution values from the last successful invocation of the external solver using the following:
instantiate_solution(Handle) :-
lp_get(Handle, vars, Vars),
lp_get(Handle, typed_solution, Values),
Vars = Values.
Destroy the specified solver state, free all memory, etc. If the solver state is associated with an eplex handle, the solver state is disassociated with the eplex instance. However, unlike eplex_cleanup/0, the outstanding constraints not yet collected by the solver is not removed.
As with eplex_cleanup/0, care should be taken before using this non-logical predicate.
Read a problem from a file and setup a solver for it. Format is lp or mps. The result is a handle similar to the one obtained by lp_setup/4.
=:= Y, X >= Y or X =< Y
where X and Y are arithmetic expressions.
The linear constraints are returned in normalised form in NormConstraints,
the nonlinear ones are returned unchanged in NonlinConstr.