[Coin-discuss] re: Preserving row and column names using readLP & OsiSolverInterface

[Matthew Saltzman]

Are there unit test changes in the offing related to this issue? 
Currently, the OSI unit test fails (at least with CPLEX) when saving and 
reading back a problem with non-unique row names.

On Mon, 6 Feb 2006, Matthew Saltzman wrote:

> On Mon, 6 Feb 2006, Francois Margot wrote:
>
>> 
>> John:
>> 
>> I will make the changes. Note that, as far as I know, it is impossible
>> to specify ranged constraints in the "Cplex" LP format
>> (see http://plato.asu.edu/cplex_lp.pdf). They have to be written
>> as two separate constraints.
>
> Or as equality with explicit bounded slack.
>
> I tried setting a bound on a constraint in CPLEX, but it appeared not to do 
> the right thing.
>
> 		Matt
>
>
>> 
>> Francois
>> 
>> 
>> On Mon, 6 Feb 2006, John J Forrest wrote:
>> 
>>> Francois,
>>> 
>>> OK - tighten restrictions on row names but then writeLP should be changed.
>>> writeLP must produce a valid model from a valid model.  Either it must be
>>> enforced that changeNameOnrange be true or a better alternative is to
>>> write out the ranged constraint correctly.
>>> 
>>> John Forrest
>>> 
>>> 
>>> 
>>> Francois Margot <fmargot at andrew.cmu.edu>
>>> Sent by: coin-discuss-bounces at list.coin-or.org
>>> 02/04/2006 08:54 AM
>>> Please respond to
>>> Discussions about open source software for Operations Research
>>> <coin-discuss at list.coin-or.org>
>>> 
>>> 
>>> To
>>> Discussions about open source software for Operations Research
>>> <coin-discuss at list.coin-or.org>
>>> cc
>>> 
>>> Subject
>>> Re: [Coin-discuss] re: Preserving row and column names using readLP     &
>>> OsiSolverInterface
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Thu, 2 Feb 2006, John J Forrest wrote:
>>> 
>>>> Francois,
>>>> 
>>>> I strongly disagree.  If there are no names or no duplicates then the
>>> code
>>>> I added is not invoked.  If there are duplicates then without my change
>>>> accessing some row names will give a segmentation error.  The hash
>>>> functions are never used for row names and it is only row names I am
>>>> checking.
>>> 
>>> First, there is now a memory leak: since stopHash(0) sets numberHash[0] to
>>> 0,
>>> when the CoinLpIO object is deleted, the array names_[0] is not freed
>>> properly.
>>> 
>>> Second, the method CoinLpIO::rowIndex() now sometimes behaves incorrectly:
>>> 
>>> asking for the index of a row having a particular name always returns -1,
>>> i.e. it claims that no name is in the list of row names.
>>> 
>>>> 
>>>> So I think my solution does not harm anyone and helps people who have
>>>> duplicates.
>>> 
>>> One bug is replaced by two. I am not convinced that this is an improvment.
>>> 
>>> I think that we have to decide if we want to support duplicate row names
>>> or not. In the current implementation, the warning that is printed when
>>> non distinct row names are identified was intended to warn the user that
>>> strange behavior (including possible seg faults) might come from that
>>> fact.
>>> 
>>> If we want to fully support identical row names, I see 2 possibilities:
>>> 
>>> 1) Remove hash tables for row names and replace them by a vector. This
>>> requires
>>> changes in several methods dealing with row names.
>>> 
>>> 2) Have hash tables storing duplicates. Requires a new set of hash table
>>> methods.
>>> 
>>> In addition, we have to provide a method that returns all the indices of
>>> rows
>>> having a given name.
>>> 
>>> The other possibility (my preference) is to tighten the restrictions on
>>> names:
>>> all row names must be distinct. If non distinct names are provided, then
>>> either an error is raised or the names are automatically replaced by
>>> default
>>> names.
>>> 
>>> I can make the changes once we agree on what we want to do.
>>> 
>>> Francois
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Coin-discuss mailing list
>>> Coin-discuss at list.coin-or.org
>>> http://list.coin-or.org/mailman/listinfo/coin-discuss
>>> 
>>> 
>> _______________________________________________
>> Coin-discuss mailing list
>> Coin-discuss at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/coin-discuss
>> 
>
>

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs