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

[ajking at mac.com]

So now that that week is over and I have more energy, here is some 
proposed documentation for SmiCoreCombineRule class.  Any comments 
welcome!
========================

The class SmiCoreCombineRule is an updater object for SmiScnModel.  
Users can derive an updating object from SmiCoreCombineRule and pass it 
as an argument to generateScenario() and readSmps().

SmiCoreCombineRule methods are called inside SmiScnModel.loadOsi.  The 
basic rule is that objects declared in the CORE object get updated by 
elements of the STOCH object using SmiCoreCombineRule methods.

===========================

Alan King
http://www.coin-or.org/

On Jun 2, 2005, at 10:08 PM, Alan King wrote:

>
> Classes derived from the base class SmiCoreCombineRule define how core 
> and scenario data are to be combined when the deterministic equivalent 
> is generated.   It is quite simple to grep the code and see where and 
> why these classes are invoked.  
>
> Rather than continue to debate the SMPS standard -- going on for 
> almost 20 years now  -- I decided it would be better if users could 
> provide their own rule to readSmps().  For example, a user could 
> decide to use multiplication as the basic combination operation just 
> by providing the appropriate SmiCoreCombineRule class.  An example of 
> this pattern is used to read Francois' bug example in 
> Coin/Examples/Stoch/stoch.cpp.
>
> On the other hand, an energetic person could take the responsibility 
> to develop a workable community concensus for the SMPS standard and 
> write the appropriate SmiCoreCombineRule classes.
>
> Alan
>
>
> Francois Margot <fmargot at andrew.cmu.edu>
>
> Sent by: coin-smi-bounces at list.coin-or.org
>
>
> 05/30/2005 09:59 AM
>
> To
>
> coin-smi at list.coin-or.org
>
> cc
>
> Subject
>
> Re: [Coin-SMI] Re: Re: Changing right hand side of inequalities
>
>
>
>
>
>
>
>  >
>  > 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.
>  >
>
>  It is ambiguous only if you assume that inequalities are defined with 
> a lower
>  and an upper bound (i.e. ranged constraints). Otherwise, the rhs is 
> one
>  of the two and any request to change the rhs is unambiguous. Since MPS
>  files require that each inequality is identified as a "<=", ">=" or 
> "="
>  constraint, I would consider that changing the rhs of such a 
> constraint
>  means changing the value of the rhs without changing the type of the
>  inequality. Only for ranged constraints (that are indeed allowed to 
> appear
>  in a MPS file), the request is ambiguous.
>
>  In any case, all this is just bickering. My point is that the actual
>  implementation of readSmps() could be improved to be able to model
>  a larger class of problems using core, stoch and time 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.
>
>  I understand that the problem is in readSmps(). I want to improve it,
>  no work around will make me happy.
>
>  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
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5476 bytes
Desc: not available
Url : http://list.coin-or.org/pipermail/smi/attachments/20050606/2a166bc4/attachment.bin