[Coin-osi-devel] row & column names, anyone?

[Matthew Saltzman]

On Tue, 6 Feb 2007, Lou Hafer wrote:

> Folks,
>
> 	As I work on cbc-generic (cbc for generic OSI solvers), I've reached the
> point where row and column names are next on my list of things to do.  Far and
> away the most sensible thing (from where I sit, anyway :-) is to put this
> capability into OsiSolverInterface.  Where problem import/construction does not
> provide names, it's trivial to construct something (rowNNN, colNNN, or similar).
>
> 	Does anyone object?

Not me.  It's been on the list for a while.

Before you start to code, though, I'd like to see you post a a complete 
spec (all relevant methods with parameters, return values, and actions) so 
we can discuss the functionality to be included and maybe the 
implementation.

The basic ideas below look reasonable to me, but I'm interested to hear 
what others think about whether we need (1) and whether we have all the 
functionality users would want (or at least haven't blocked functionality 
that we are going ot want to add later.

 		Matt


>
> 	If there are no objections, I'll likely set up an integer parameter
> along the following lines, with necessary support functions (suggestions
> welcome):
>
>  0: No names:  No static name information is retained.  Attempts to set a
>     row/col name are quietly ignored.  Requests for the name of an individual
>     row/col always return rowNNN/colNNN.  Requests for vectors of names
>     return null.
>
>  The notion here is that you can be sure a request for an individual name will
>  always generate a string (makes it easier to do debug messages).
>
>  1: Client names plus lazy generation:  Row/column name information supplied by
>     the client (via mps, gmpl, or explicit set row/col name) is retained.
>     Requests for the name of an individual row/col name return the name
>     supplied by the client or rowNNN/colNNN.  Requests for arrays of names
>     return a reference to a vector sized to accommodate the largest index for
>     which the client has supplied a name. The vector may contain null entries.
>
>  So, if you read in an mps problem, then add a bunch of cuts, but supply no
>  names, if you ask for the vector of row names, it'll be the size of the
>  original problem. If you assign a name to the 5th cut, you'll get a vector
>  with entries up to the 5th cut, and null entries for cuts 1 -- 4.
>
>  2: As 1, but names are aggressively generated as rows/columns are added, if
>     not supplied by the client. Vectors of row or column names will always be
>     the size of the current constraint system and will contain no null entries.
>
> For ease of coding, names will be std::string, arrays of names
> std::vector<std::string>. I'll lay on a reasonable set of access functions to
> set/get row and column name arrays and individual row and column names.
>
> At least in the first cut, this won't cope with major transformations (pre/post
> processing, presolve, etc.). May come later if it looks straightforward.
>
> 							Lou
>
> _______________________________________________
> Coin-osi-devel mailing list
> Coin-osi-devel at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-osi-devel
>

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs