[Osi] issue in OsiCbc - corrupting bounds

[Lou Hafer]

Matt,

> I guess OSI solver independence is not really possible when doing MIP stuff?

	Well, my feelings about OsiCbc haven't changed, and using OsiCpx doesn't
really make a difference.  It's still doing brain surgery in boxing gloves.

	That said, it should be possible to do a lot better, both in terms of
providing the right hooks for MIP, and in terms of enforcing common behaviour
(solver independence).  Solver independence has received short shrift in the
past when it conflicted with efficiency or the urgent need for working code.
It'll take some time to reverse this drift without losing efficiency.  And it's
a difficult sell to solver developers, who tend to focus on their own codes for
all sorts of good and bad reasons.

	Flipping over to the question of controlling MIP, we've had this debate
in the waaaay distant past, far enough that I've forgotten most of it.  If I
recall, the last round sort of foundered on the question of how to create a
flexible and expandable parameter set.

	Matt and I are of the opinion that it would be a good thing to remove
the OsiSimplex API from the base Osi API, which is just too bloated.  This may
well happen in the next few months; it's a blocker for me as I do OsiDylp
development, on the way to restoring cbc-generic (i.e., the capability to use
cbc with a generic Osi).

	We were also looking at the idea of additional APIs --- an OsiBaC API,
for instance --- to house some of the methods that have been stuffed into
OsiSolverInterface in support of BaC.  This provides an expansion path to other
classes of problems.  In effect, one assembles an Osi for a problem class by
implementing the appropriate set of APIs.  (If you think of this in terms of
Java interfaces, which are then implemented by classes, you'll have the right
mental model.)  This partially escapes the `flexible and expandable parameter
set' bind by allowing each API to define its own set.

							Lou