[Os-project-managers] sparseObjects

[Kipp Martin]

A major item of contention seems to be our handling of sparse objects,
both in our schemas and in the C++ implementation. In preparation for
the next meeting, where I hope we will have a chance to discuss the
items and hopefully come to a resolution, I summarize below the
discussion Kipp and I had on the issues.

First, in the schemas we have a variety of objects such as IntVector,
PositiveIntVector (and various other modifications of IntVector),
DoubleVector, LinearCoefficientMatrix (with three separate vectors),
ConstantMatrix (which differs from LinearCoefficientMatrix in the use
of mandatory "numberOf..." attributes).


To elaborate,  The class LinearConstraintCoefficients,
has three members two of which are class  IntVector and one DoubleVector.
That is, we have:

DoubleVector *value;
IntVector *start;
IntVector *rowIdx;

None of the above have an exact correspondence in the schema.
In the C++ code we have nothing that corresponds to, for example,

NonNegativeIntVectorWithValueAndDescriptionAttribute

In the C++ code we have, but do not implement, an IndexValue Pair.

Implemented in C++ is a vector (such as IntVector), an IndexValuePair,
SparseVector and SparseMatrix. We are not consistent in our translation
from the schema representation to the C++ implementation. For instance,
the vector of objective coefficients in OSiL is represented in the
schema as an array of elements with two components: a double value and
an attribute "idx", which should be translated as an array of
IndexValuePair according to our constitution, but is implemented in the
C++ code as the class SparseVector which has two pointers, an
integer pointer 'indices',  and a double pointer 'values'.
Kipp acknowledges that he broke the  constitution in his implementation.


We have several questions to deal with: What should the data structure
look like in C++? (The two vector implementation is probably more
efficient than the array of IndexValuePairs.) What should the schema
look like? (If we make the schema conform to Kipp's implementation, we
have to change the version number to 3.0 --- no question.) Further in
terms of implementation, can we refer directly to COIN objects where
these exist (via COIN header files), should we copy the COIN code into
OSGeneral, or should we implement our own data structures entirely?

If you get a chance, please think of these items before our next
meeting. Kipp and I discussed possible times and suggest next
Wednesday, October 6, 1:30 CDT. Hope this works for everybody.
-- 
Kipp Martin
Professor of Operations Research
and Computing Technology
Booth School of Business
University of Chicago
5807 South Woodlawn Avenue
Chicago, IL 60637
773-702-7456
kmartin at chicagobooth.edu
http://www.chicagobooth.edu/faculty/bio.aspx?person_id=12825325568
http://projects.coin-or.org/OS