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

[Ted Ralphs]

Just as a second opinion, I say "hear, hear!" It's been needed badly for 
a long time. I'm actually not sure how people use Osi without it in some 
cases. It would be nice to have a lookup table, too, so you can find out 
the index of an object with a given name, if that's not too much to ask :).

Cheers,

Ted

Matthew Saltzman wrote:
> 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
>>
> 


-- 
Dr. Ted Ralphs
Associate Professor
Industrial and Systems Engineering
Lehigh University
(610)758-4784
tkralphs at lehigh.edu
www.lehigh.edu/~tkr2