[Coin-osi-devel] row & column names, anyone?
tkralphs at lehigh.edu
Tue Feb 6 21:19:41 EST 2007
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 :).
Matthew Saltzman wrote:
> On Tue, 6 Feb 2007, Lou Hafer wrote:
>> 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
>> 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
> 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.
>> If there are no objections, I'll likely set up an integer parameter
>> along the following lines, with necessary support functions (suggestions
>> 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
>> 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
>> 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
>> 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
>> 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
>> 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
>> processing, presolve, etc.). May come later if it looks straightforward.
>> Coin-osi-devel mailing list
>> Coin-osi-devel at list.coin-or.org
Dr. Ted Ralphs
Industrial and Systems Engineering
tkralphs at lehigh.edu
More information about the Osi