[Coin-discuss] development tree / idea about the OsiSolverInterface base class

[Laszlo Ladanyi]

I'd advise that people start to use the development version of COIN.
To get the devel tree you have to use cvs, there is no daily tarball.
Simply use 'cvs checkout -r devel <module_name>'.

Advantages: 
- The OsiSolverInterface class is significantly extended. It does
  almost everything now. 
- BCP has a mostly complete documentation

Disadvantages:
- Osl and Vol interfaces are completely updated and tested. The Cpx interface
  is update, too; Tobias Pfender has already committed lots of stuff, we just
  have to test it. The Xpr interface is not yet updated.

=====

An idea that I think would be good to implement and I'd like to solicit
comments: 

Right now the OsiSolverInterface base class has no data members (of any
importance). The individual solverinterfaces have to override every member
method for data handling. I think it'd be nice to have arrays in the base
class which *could* contain the problem data if the solverinterface wants
that. What I mean is that:
- there would be pointers in the base class which are NULL by default
- if the solverinterface overrides the data handling routines (I imagine
  interfaces to every commercial solver would do this for efficiency reasons)
  then these pointers would never be used and almost no space is wasted
- other solvers, like Vol, could use the already implemented data handling
  methods (the matrix would be there, the PackedMatrix class has methods to
  add/remove column(s)/row(s), those would be there, there would be place for
  the primal/dual solutions, etc.). All the derived solver would have to
  override is the various solve routines, warmstart/hotstart related methods,
  and maybe a few others. This way solvers could have not only a uniform
  interface but a uniform way of storage, too. This means easier maintenance,
  easier testing.

What do you think?

--Laci