[Coin-osi-devel] Spec for row/column name handling, with first cut at code.

[Lou Hafer]

Folks,

Francois writes
 
> It would be nice if the way default names work in Osi, 
> OsiXXXSolverInterface, CoinMpsIO and CoinLpIO is similar.
> 
> ... a name for the objective function should probably be included. 

	Yes. I noticed that LpIO had this, will check MpsIO. GMPL returns an
	MpsIO object, so I expect it'll be similar.
> 
> Second, in CoinMpsIO and OsiClpSolverInterface, default row names are 
> RNN (R%7.7d), default columns 
> names are CNN (C%7.7d). In CoinLpIO, they are respectively consNN and xNN. 
> The R%7.7d and C%7.7d conventions are rather ugly for an LP file, but the
> fixed length might be useful for MPS files. In any case, ColNN is wasteful
> for LP files. I would prefer CNN or xNN. Probably RNN would be then better
> for the default row names.

	Sigh. Where's your sense of aesthetics?  :-). But not a problem, I
	can easily wire this in.
	
> Maybe enforce rules for names: maximum length, possibly character set.
> 
> Lookup for names is important. Is it allowed to have two identical row
> names or two identical column names? What happens if the user defines
> name "Row2" for row with index 0, no name for row 2 and asks for the
> name of row with index 2? Without a lookup table for names, it is impossible
> to quickly test for these conflicts.

    This is an uglier issue.  Right now, I'm counting on Mps/Lp/GMPL/
    CoinModel parsing routines to deal with this sort of thing when they're
    used for input.  I'd argue against getting into the business of enforcing
    rules for names.  Let the client do as they please, keeping in mind output
    formats will enforce their own rules.  Because many of the key routines
    for row/column addition/deletion are pure virtual, there will be severe
    limits on any enforcement.  I'd argue partial enforcement is worse than
    none at all.
    
    I do intend to try for some sort of lookup. But the OSI facility is not
    intended to support general-purpose manipulation of models by name.
    CoinModel and various model generation languages already do that.

> It seems to me that the "lazy" handling of names is overly clever and might
> creates problems. It is simpler to have the default names mode (where
> the user gives up control of names) or user names mode (where the user 
> takes care of all names, and names must be provided upon generation). 
> In lazy mode, what happens when rows are removed?

    I need to provide a delete[Row|Col]Name routine.  Realised that while
    thinking about this on the bus last evening.  But I don't see the lazy
    handling as creating problems --- it makes things easier.  The `first-cut'
    implementation works with `no names' and `lazy names'.  `Full names' is
    generated on the fly, if needed, when a name vector is requested.

    The main motivations for `lazy names' are what I see as typical usage in
    branch-cut-price solvers, and the limitations of pure virtual functions.
    The core constraint system is going to be created with some care, and
    names might have some significance and can be reliably captured.
    Installation of cuts and columns is usually handled through pure virtual
    functions defined in the derived OsiXXX solvers.  And there are
    potentially 10's of thousands of them, which come and go quickly.  If a
    client wants to manage name generation, etc., fine by me.  Otherwise, the
    OSI name facility simply doesn't have to care.  When the client asks for
    the name of the cut at index 100, they'll get a generated name.  That name
    will simply reflect `constraint in row 100', without regard to whether
    the constraint in row 100 has been changed five times since the last time
    the name was generated.

    						Lou