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

John J Forrest jjforre at us.ibm.com
Mon Feb 6 09:15:25 EST 2006


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/coin-discuss/attachments/20060206/4be35567/attachment.html>


More information about the Coin-discuss mailing list