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

[fmargot at andrew.cmu.edu]

Lou:

On Thu, 8 Feb 2007, Lou Hafer wrote:

> Folks,
>
> Francois writes
>
>> 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.

I think "lazy names" is not useful, at least from a user perspective.
It seems to be more an implementation issue. From the user point of view, 
I see three main modes:

0: User don't care about matching names with constraints of variables. User 
will never ask for such information (except possibly to write the model in a
file for which default names can be used).

1: User would like to have a name associated with each constraint/variable, 
the name being used for one particular constraint/variable from begin to 
finish. User would like default names generated for him.

2: User would like to have a name associated with each constraint, the name
being used for one particular constraint from begin to finish. User
specify the name at generation time (names read from an input file are
kept).

For 1, I don't know what to do with names read from a file. On one hand,
the user would probably like to keep them, but on the other hand the
default names might conflict with the names read.

Francois