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

[ajking at mac.com]

On May 29, 2005, at 8:08 AM, Francois Margot wrote:

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

SMPS is silent on these points.  So is, for that matter, MPS.  It is a 
fundamental ambiguity built into the standard.
In the case of the direct interface, nothing needs to be documented at 
all.  It will always do what the user intends.

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

As we have said, SMI does handle inequalities.  The example you 
provided is easy and natural to code in the direct interface.  The 
issue is how SMPS should 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 have already written one -- it is called a "C" input file.  The 
question really is: what input patterns would you like to use?  I would 
like to be able to use a modeling language.
>
> 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.
>
Yes, point well taken.

> Francois
>
>
>>
>> I use the smps cases for regression testing, mainly.
>
> I have no idea what this means.
>
A regression test is a software development term.  Passing a regression 
test means that your revisions work against some archive of tests.  
There are archives of SMPS tests -- see the website //stopro.org for a 
list of these.  readSmps() *should* run POSTS and Watson just fine, but 
I haven't actually downloaded the files and run them in a while.

>>
>> 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'll put a disclaimer in the code.

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

Where would you like to see the disclaimer appear?

>>> 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
>>
>>
>>
> _______________________________________________
> Coin-SMI mailing list
> Coin-SMI at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-smi