[Coin-discuss] re: Preserving row and column names using readLP & OsiSolverInterface
Matthew Saltzman
mjs at ces.clemson.edu
Mon Feb 6 14:29:28 EST 2006
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
More information about the Coin-discuss
mailing list