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

[Lou Hafer]

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?
	
	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