[Coin-osi-devel] OSI name support / disconnect with underlying OsiXXX

Lou Hafer lou at cs.sfu.ca
Mon Feb 26 16:16:45 EST 2007


Folks,

	I'll stay away from the `general name <-> object mapping' issue that Ted 
identifies. He's correct, but this'll be long enough without getting into that.
	
	It is indeed up to the application to track how the underlying
constraint system changes.  The OSI unit test enforces the requirement that the
relative order of rows and columns not change.  (Yes, I'm sure about that. Dylp
in native mode moves the last row or column into the empty position to get
constant time deletion :-).

	With names, I'm going for something simple.  All I'm after is the
ability to attach a name to an index for output and debugging.  The core
obstacle is that the current OSI interface provides no way to pass names down to
an OsiXXX class.  And I don't want to introduce any new pure virtual functions;
that'd be an immediate show-stopper, as every OsiXXX maintainer would have to
implement the functions or fail to compile.  (It's true that our present X.Y.Z
naming scheme would deal with this, but it'd still be disruptive.)

	The challenge is to do as much as possible within this constraint.  I've
tried to do as much as possible in the OSI base with impure virtual functions,
and document where OsiXXX maintainers need to override and/or augment to keep
names properly synchronised. And keep this work to a minimum, to encourage 
adoption.

	That gets me to the `less disruptive but deceptive' approach.  It's
actually the reverse of Ted's interpretation.  The underlying OsiXXX class
remains utterly ignorant of the names cached in the OSI base class, unless the
OsiXXX implementer does the necessary overrides and tweaks to existing code.

	Turns out you can get a fair ways.  The OSI bulk import routines
(readMps, readLp, loadFromCoinModel) are impure virtual.  I can grab names there
for the core constraint system (as long as the OsiXXX class hasn't overridden
them).  A large class of applications never alter the core constraint system, so
these names remain in sync. By generating all other names on the fly (`lazy 
names'), the OSI base class doesn't have to worry about additions/deletions of 
rows and columns beyond the core.

	I'm at the point of testing this in cbc and cbc-generic.  So far, so
good. Preprocessing may be a challenge.

	The group of people most likely to see a `name disconnect' between the
OSI base and the OsiXXX class are folks doing serious development of branch-
cut-price codes who are looking at debugging messages and output generated by
the application (cbc, symphony, bcp, etc.)  and the underlying solver (clp,
dylp, cplex, etc.).  Even then, it'll only bite you if your application assumes
a generic OSI interface and the underlying solver doesn't provide any name
support.  The clp-specific main program for cbc, for example, should not have a
problem because it taps clp's non-standard name facility directly.

	All of which is to say I'm hoping for fairly wide utility with an
admittedly imperfect implementation.

						Lou




More information about the Osi mailing list