[Coin-discuss] Questions about OSI

[J P Fasano]

Hi to all.

We were planning to develop a C++ common interface for (mixed integer)
linear and quadratic optimization solvers. Looking on the net, we found the
web-pages of COIN. We would like to extend the OSI interface in order to
accomplish our goal.

>--------
GREAT!
>--------

Before to start, we wolud like to understand better the design of OSI and
so
we have some questions:

1) Before finding OSI, we thought to have two main abstract classes in our
interface: a class Problem for a generic linear/quadratic problem, with a
set of operations to create, modify and read the data of the problem and
solution, and a class Solver for a generic linear/quadratic solver, with a
set of operation to solve and get some information about the problem (e.g.
empty or unbound problem, etc.). We think that this approach may be
beneficial, e.g. allowing to pass the same problem to different solvers, or
to use the same solver for different problems. So the first questions that
we have is about your choice to have an unique class for the problem and
the
solver: what are the reasons that suggested (or imposed) you to have an
unique class?

>--------
Perhaps the single class represents the reality of how the solvers work
and how one can efficiently use memory.
Having a class that represented the model data which is passed to the
solver as you suggest would require passing all the data to the solver.
This would mean that there are two copies of the data in memory.
It is possible that future solvers will be able to work with the
applications copy of the data,
but this is not the case today (cplex, xpress, osl).

One could create a class that contains the model data (perhaps
OsiModelData).
It could have member data which represents the linear/quadratic problem.
The OsiSolver class could add setModelData and getModelData member
functions.
This would provide the capability of "allowing to pass the same problem to
different solvers, or
to use the same solver for different problems".

For applications that can spare the memory, it would be useful to have.
>--------


4) Why don't you use the namespace construct to avoid the OSI prefix?

>--------
This is a style issue which can get into religious wars.
-One point of view is that namespaces are just for those who did not have
the foresight to initially
use a component prefix and are now looking for a way to avoid linkage
editor name clash problems.
-When reading unfamiliar code it is nice to know which packages a
particular class comes from without
having to search all packages used by the application.

We did discuss the pros/cons and decided to go with using a prefix.
Our benevolent dictator made this decision.
>--------

5) Don't you think that the c++-style std::vector<double> should be
preferred to the c-style vector double*?

>--------
No.
All the solvers expect double*.
Using std::vector<double> will have an performance impact when passing data
to the solvers.
Osi is intended to be fast and not slow down the solvers.
>--------

In order to have the OSI interface to perform all the tasks we need, we are
planning to extend it in the following ways:

1) extend the objective function to the quadratic case;

>---------
GREAT!
>---------

4) add namespaces.

>---------
What do you mean by this?
Do you mean remove the Osi Prefix and change it to be a name space?
>---------

We would really appreciate observations, comments and suggestions about our
proposed extensions. We are especially concerned about maximizing the
possibility of having our modified version to reach the distribution point,
so that all other users can benefit from them.

>--------
We would very much like to have any enhancements you make added to the base
code.
Thanks for your careful review and thoughtful questions.
>--------

JP