<br><font size=2 face="sans-serif">Francois,</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">John Forrest</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Francois Margot <fmargot@andrew.cmu.edu></b>
</font>
<br><font size=1 face="sans-serif">Sent by: coin-discuss-bounces@list.coin-or.org</font>
<p><font size=1 face="sans-serif">02/04/2006 08:54 AM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
Discussions about open source software for Operations Research
<coin-discuss@list.coin-or.org></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Discussions about open source software
for Operations Research <coin-discuss@list.coin-or.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: [Coin-discuss] re: Preserving row
and column names using readLP &
OsiSolverInterface</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2><br>
<br>
On Thu, 2 Feb 2006, John J Forrest wrote:<br>
<br>
> Francois,<br>
><br>
> I strongly disagree. If there are no names or no duplicates
then the code<br>
> I added is not invoked. If there are duplicates then without
my change<br>
> accessing some row names will give a segmentation error. The
hash<br>
> functions are never used for row names and it is only row names I
am<br>
> checking.<br>
<br>
First, there is now a memory leak: since stopHash(0) sets numberHash[0]
to 0,<br>
when the CoinLpIO object is deleted, the array names_[0] is not freed properly.<br>
<br>
Second, the method CoinLpIO::rowIndex() now sometimes behaves incorrectly:
<br>
asking for the index of a row having a particular name always returns -1,
<br>
i.e. it claims that no name is in the list of row names.<br>
<br>
><br>
> So I think my solution does not harm anyone and helps people who have<br>
> duplicates.<br>
<br>
One bug is replaced by two. I am not convinced that this is an improvment.<br>
<br>
I think that we have to decide if we want to support duplicate row names<br>
or not. In the current implementation, the warning that is printed when<br>
non distinct row names are identified was intended to warn the user that<br>
strange behavior (including possible seg faults) might come from that fact.<br>
<br>
If we want to fully support identical row names, I see 2 possibilities:<br>
<br>
1) Remove hash tables for row names and replace them by a vector. This
requires<br>
changes in several methods dealing with row names.<br>
<br>
2) Have hash tables storing duplicates. Requires a new set of hash table<br>
methods.<br>
<br>
In addition, we have to provide a method that returns all the indices of
rows<br>
having a given name.<br>
<br>
The other possibility (my preference) is to tighten the restrictions on
names:<br>
all row names must be distinct. If non distinct names are provided, then<br>
either an error is raised or the names are automatically replaced by default
<br>
names.<br>
<br>
I can make the changes once we agree on what we want to do.<br>
<br>
Francois<br>
<br>
<br>
<br>
_______________________________________________<br>
Coin-discuss mailing list<br>
Coin-discuss@list.coin-or.org<br>
http://list.coin-or.org/mailman/listinfo/coin-discuss<br>
</font></tt>
<br>