[Coin-osi-devel] A bit more OSI2 discussion

[Lou Hafer]

Folks,

	Time to spark another round of Osi2 design discussion. Kipp's
captured a lot of what I had in mind; there are also a few points where I'll
go in a slightly different direction. I'll go with Kipp's use of instance
(staying away from model), and keep my use of transform. Mainly I want to
extend and clarify the notion I had for transforms and the transform
manager.  I didn't see a good way to interleave this into the wiki page,
hence the email. I've added this as an attachment to the page.

	Kipp's notion of a base virtual OsiXForm class is just what I had in
mind, as are the derived transform classes. (I'll argue transform is the
appropriate word for these classes, but mainly so we can save `Mod' to use in
class names for modifiable instances  :-). I'd suggest that the key
methods for any OsiXForm should be modify() and unmodify() (or xform() and
unxform()).  Then one could scan an OsiXFormRec (a list of transforms)
forward or backward (for pre/post processing applications).

	I was thinking that an OsiXFormRec would be combined with an
OSInstance, with some data structure designed for efficient manipulation of
the instance (OsiModRep?), and with an OsiXFormMgr (transform manager) so
that all four components form an OSModInst (modifiable instance) class. We
might want to add an OSResult class to the components. And likely some sort
of caching structure for efficient processing of common actions.

	The functionality I have in mind for the OsiXFormMgr is something
very much like an intelligent disk controller. It collects all transform
requests in a single list (Kipp's modObjects) of OsiXForm objects. It has
sufficient intelligence to scan the list and batch adjacent transforms for
efficiency, when so requested. We can start simple here (combining adjacent
add/delete row/column operations, for example) and work up to more
complicated mergers.

	Recall that I want to interpret `solver' very generously, as any class
with interest in tracking changes to the model instance and/or manipulating
the instance. To keep the solver interfaces (OsiXxxSI) simple, we'll want to
define a small set of primitive operations that are mandatory.

	But there's a related problem: If the transform list is just a sequence
of primitives, the semantics can get lost (for example, there's no a priori way
for an OsiXxxSI to know that a sequence of row deletions is really intended to
mean `drop these loose cuts and compress the basis'). As another example, it
may well be that a hueristic can guarantee that the sequence of transforms it's
about to send will not change the current solution. In general, there's no way
for the OsiXFormMgr to know this, but the heuristic could insert markers to
make this explicit. 

	One way to address this would be to explicitly indicate semantics in
the transform record. To continue the example, there might be an
OsiXFormCompressBasis class. It's xform() method would enqueue a start marker
(with semantics something like `maintain basis across this next batch of
operations'), a bunch of delete row operations, and an end marker. On the
OsiXxxSI side, an implementor could elect to simply set an internal flag
while processing the primitive operations, or create a special purpose
routine that would consume all activities between the markers. On the
OsiXFormMgr side, the markers could serve as a warning that a row deletion
preceeding the marker should not be batched with a row deletion following the
marker. We'll need to work out some sort of coding that indicates what a method
should do when it doesn't recognise a particular semantic marker.

	This is a good moment to say that I'm skeptical of the utility of
maintaining lists of individual types of transforms (Kipp's callModClasses()
and related). It seems to me that we always need to consider the sequence of
all transforms --- considering the collected sequence of one type, with other
types excised, would be dangerous. Also, for easy cloning and reentrancy, we
likely want to avoid static data structures.

	Solvers can operate in various modes:

  * A solver can initiate a query to the instance through the OsiXFormMgr and
    get a set of primitive instructions for updating its internal
    representation of the instance.

  * A solver could register with the OsiXFormMgr to receive change
    notifications. Some solvers might prefer to receive notice of each change.
    Others might want notification only when triggered by a particular event
    (a solve() request to the OSModInst, for example), or a digest whenever
    the OsiXFormMgr concludes that it's collected a maximual length batched
    sequence.

Somewhere about this point, I got to thinking that maybe the OsiModRep class
should be treated as another `solver', with limited functionality (it accepts
and processes transforms, but never initiates them).

	Individual solvers (or perhaps the transform manager) would maintain
a pointer into the transform list. Transforms prior to the pointer have already
been communicated to the solver. Transforms after the pointer have yet to be
passed across.

	Better quit before this gets too long to read.

								Lou