[Coin-SMI] Re: Re: Changing right hand side of inequalities

[Francois Margot]

On Sun, 29 May 2005 ajking at mac.com wrote:

> SMI assumes nonzero stochastic data adds to or replaces something in the core 
> data.  When you have an explicit lower bound and an implicit upper bound then 
> the software has to decide how to interpret a request to change the "right 
> hand side".  Does it go to the upper bound or the lower bound, or both?  I 
> prefer the precision of the direct interface, and it is easier to maintain 
> and debug.

Whatever the convention is, it should be documented, at the very least. 
Moreover, it seems to me that the convention should be that for an inequality
with either upper bound +infinity or a lower bound -infinity and the other
bound finite, any request to change the rhs should mean to change the finite
one. For equalities, or if both upper and lower bounds are equal, it should
mean to keep an equality, i.e. changing both bounds to the new value.

Alternatively, the mps file indicates if a constraint is "<=", ">=" 
or "=", so it seems
natural that a change in the rhs for them mean changing the upper bound
for <=, changing the lower bound for ">=" and changing both for "=".
If a user wants to transform an equality into an inequality or vice-versa
or work with ranged constraints, he can work with two inequalities instead of 
an equality.

There is no need to treat the case where both bounds are infinite, as I
believe that there is no input file that will require that. Equivalently,
any convention could be used in that case, just document it.

Note that we are not talking about several changes in the rhs: we read an
inequality and we then want to change the rhs for a specific scenario. It is
then possible to have "vanishing" inequalities, setting lower bound to 
-infinity and upper bound to +infinity in a specific scenario. This does
not create difficulties, as the rhs is changed at most once.

I agree that coding the example might be more precise, but I would expect
smi to be able to handle inequalities in input files. The way the conventions
have been chosen, it seems that smi.readSmps() is useless if changes
in the rhs are necessary. Is there a way to write input files that will make
the bug example work with the current code?

I believe that changing the convention amounts to add a test on the current 
lower/upper bounds on a row and changing the appropriate one(s). Hardly a 
major change, for a non negligible benefit.

Francois


>
> I use the smps cases for regression testing, mainly.

I have no idea what this means.

>
> Alan King
>
>
>> 
>> 
>> On Sun, 29 May 2005, Alan King wrote:
>> 
>>> Well it's a good point.
>>> 
>>> The question is how much effort is anyone willing to put into SMPS.  My
>>> personal opinion is that modeling languages are the way to go, and if you
>>> need to interface with databases and filesystems then some big company
>>> like IBM should make it easy for you.  But that isn't the case, yet, so we
>>> have to think about interfaces.
>>> 
>>> If there is an interface that works and is fast then use it.  IMHO
>>> 
>> 
>> The problem is that there is no disclaimer of any sort with the library,
>> stating that using input files is buggy. If there are method to read
>> files, they should work.
>> 
>> I don't know the code well enough to fix it. I tried to locate where the 
>> changing of rhs occur, I could not even do that. I would be surprised
>> if fixing this takes more than a couple of hours for somebody knowing the
>> code.
>> 
>> Francois
>> 
>> _______________________________________________
>> Coin-SMI mailing list
>> Coin-SMI at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/coin-smi
>
>
>