[Coin-discuss] several questions

[Matthew Saltzman]

On Wed, 14 Nov 2001, Brady Hunsaker wrote:

> I am actually using COIN's OSI for some research for the first time
> and I have come up with three questions.  Answers to any would be
> appreciated.
>[...]
> 2.  My department doesn't have OSL (I've requested that they install
>     it since it's free) so I use CPLEX at school.  I'm working with
>     solving the relaxation of a MIP and checking for fractional values
>     that should be integral.  This isn't working for me.  To solve the
>     relaxation, OsiCpxSolverInterface::initialSolve() converts the
>     problem to type CPXPROB_RELAXED, which makes sense.
>     Unfortunately, CPLEX then won't give information about whether
>     variables are integer or continuous.  The CPLEX function that
>     won't work is CPXgetctype(), which is necessary for COIN's
>     isContinuous, isInteger, getFractionalIndices, etc.
>
>     As I see it, this is a bug in CPLEX's callable library (I think we
>     have version 7.0).  Has anyone dealt with this problem?  I
>     considered working around it by modifying
>     OsiCpxSolverInterface.cpp, but this doesn't look too wise.  The
>     most likely workaround is to change the problem type to
>     CPXPROB_MIP before checking the types and then changing back
>     afterwards, but all of the functions like isContinuous are
>     declared const, since they're not supposed to change the problem.
>     For now, I plan to work around it by keeping type information in
>     my program and implementing my own equivalent of
>     getFractionalIndices.   Any thoughts on a COIN-based solution?

Some might want to hang me by the thumbs for suggesting it, but there's no
C++ mechanism to enforce const-ness of the solver's internal
representation of the problem (at least for CPLEX, OSL, XPRESS, as they
are all C-based).  One can be true to the spirit of the law, if not the
letter, by having the integrality-checking routines in
OsiCpxSolverInterface do as you propose:

	(1) Save the current problem type.
	(2) Set the problem type to CPXPROB_MIP.
	(3) Get the integrality data.
	(4) Change the problem type back to the saved value.

Before taking this advice, one would want to make sure that other aspects
of the internal representation are not changed or are properly restored
when changing problem type.

I'm not sure now (but I'll try to check) if this CPLEX behavior has
changed from 6.6 to 7.0 or from 7.0 to 7.1.

Do these methods not pass their unit tests?  Or is there no unit test that
tickles this bug?  I'm traveling, but I'll try to propose a fix in the
next week or so if Laci doesn't beat me to it.

--
		Matthew Saltzman

Clemson University Math Sciences          Editor, INFORMS Online
mjs at clemson.edu                           iol_editor at mail.informs.org
http://www.math.clemson.edu/~mjs          http://www.informs.org