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

[Francois Margot]

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.

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
>
>