[Coin-lpsolver] OsiSimplexInterface behaviour

[Mikhail Nediak]

On Fri, 11 Apr 2003, Lou Hafer wrote:

>
>
>
> > > (Lou)
> > >
> > >  << Context is behaviour of solvers when OsiSimplexInterface is enabled.
> > >     Question (broadly) is the effect/implications of asking a solver to
> > >     perform a pivot sequence that might normally be considered a violation
> > >     of the rules for the current simplex phase. >>
> > >
> > > 	Does a solver really need to be `in a phase' at all times? Well, no,
> > > not really. The various checks (in dylp, at least) really are sanity checks.
> > > Given a phase, you can assume certain things shouldn't happen. That allows
> > > some simplifications in the code. Violations are normally a good indication
> > > of a coding error. So being in a phase serves a useful purpose.
> > >
> > > 	Now I've written that last paragraph, I guess I'd say the real problem
> > > is that dylp assumes that if it's doing simplex pivots, then it's in one of
> > > primal I, primal II, or dual II. It probably wouldn't be too difficult to
> add
> > > a `no phase' phase (:-) to various specific routines (pivot, factorization).
> >
> > (Mikhail)
> >
> > OK. But then it probably makes sense to have a "richer" enabling routine
> > in OsiSimplexInterface. We should have at least three modes: primal, dual
> > and "neither". There is also an issue of what OsiSolverInterface calls
> > would be allowed in either of these modes. E.g., would adding a row while
> > in "primal" or "column" while in "dual" be allowed? How about changing
> > objective coefficients, right-hand-side, bounds? Can resolve() be called?
> > I though it would be reasonable to, at least, be able to call resolve().
> > Etc, etc, ...
>
> 	dylp could likely cope with chunks of this --- addition/deletion of
> 	rows & columns is native. Some nontrivial interface work would be
> 	required. Efficiency could be an issue where the basis inverse is
> 	augmented. The math is straightforward, but I'd have to have a hard
> 	look at Makhorin's basis package to see how an incremental update
> 	would be handled. Might be worth it. For dylp would be the potential
> 	for efficiency gains in other places.

What I meant is that some transformation can make a problem primal or dual
infeasible. So, for example, how should the solver behave when the user
tries to add an infeasible row in a "plimal" mode? The same question can
be asked for any transformation in any of the modes. I think this should
be agreed on to get useful and predictable results from
OsiSimplexInterface implementation for different solvers.

Best,
Mikhail

>
> > > 	What sort of behaviour would be expected at the transition back to
> > > solver control? Would the solver be allowed to assess it's state and proceed
> > > accordingly?
> >
> > What does transition mean? If it is a call to resolve(), should not
> > solver state assessment happen automatically?
>
> 	That's the answer I was hoping for.
>
> 	I'll have to go back and dig up the original emails and docs on
> 	OsiSimplexInterface and have a hard look. And give and mark a final.
> 	I'll dive back into this once marking is done.
>
> 							Lou
>
> _______________________________________________
> Coin-lpsolver mailing list
> Coin-lpsolver at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-lpsolver
>