[Coin-discuss] Re: SetColSolution and GetColSolution

[Matthew Saltzman]

On Mon, 4 Aug 2003, Bo Jensen wrote:

> Hi Brady,
> Thanks for the reply.
>
> "getColSolution without setColSolution should be unambiguous."
>
> Yes, but it was not clear to me what happend when you use something like:
>      setColSolution()
>      getColSolution()
> without a solve between the calls.
>
> "If you are using a cache for data, then I recommend changing the
> column values in the cache but not actually telling MOSEK."
>
> But then the user thinks the function setColSolution works fine, while the
> solver might disregard the
> start solution, and there might be big performance gaps between using the
> solvers that don't disregard the solution and those that do.  It also
> depend on what
> algorithm you choose as default.

True enough.  That's one difficulty with the current design and with any
attempt to deal transparently with different solvers with different
behaviors.  We should be able to at least partially solve most of these
problems in the new interface, but I don't see them going away entirely.
We can/should/will do better at informing users when solvers lack features
that they want to rely on.

>
> "At some point we will discuss this issue again, but it should wait for
> the OSI redesign and possibly for incorporation."
>
> Ok I will leave it for now and just implement the approach you mentioned.
> Will the redesign discussion be posted here ?

Some discussion related to problems with the current design and wishlist
items for a new design *have* taken place here.  They can be found in the
archives, though they aren't specifically associated with a "redesign"
thread.  There's also my slides from the INFORMS San Jose meeting, posted
on the resources page at www.coin-or.org.

More discussion has taken place on coin-core and at a BOGSAT meeting at
IBM three weeks ago.  (BOGSAT -> Bunch of Guys Sitting Around a Table, a
classic minimally structured policy-making methodology.)

We now have an outline for a class hierarchy that we think is buildable,
usable, and extensible.  There are still technical issues that we will be
working out while prototyping over the next couple of months.  Major
planned features include:

  - Separate model and algorithm classes.
  - A model object need not be associated with a solver until the solver
	is called.
  - Hierarchy of structured model classes (e.g., Model ->
	LinearConstraintModel -> LinearModel or QuadraticModel, depending
	on objective).
  - Hierarchy of algorithm classes (thus, full, integrated support for
	simplex, barrier, and MIP algorithms).
  - Exception-based error handling.

Those of you who are planning to be at ISMP in Copenhagen next week can
check out "Open-source software for mathematical programming" (TH2),
"Software session, COIN-OR" (WE1), and the COIN-OR business meeting
(Wednesday lunch).  (Other ISMP activities of interest are at
www.coin-or.org/ismp03.html.)  I'll post my slides from the TH2 session at
www.coin-or.org.  When we have enough pieces in place to be worth
discussing, we'll post here.

-- 
		Matthew Saltzman

Clemson University Math Sciences
mjs at clemson.edu
http://www.math.clemson.edu/~mjs