<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Alan</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-smi-bounces@list.coin-or.org</font>
<p><font size=1 face="sans-serif">05/30/2005 09:59 AM</font>
<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">coin-smi@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-SMI] Re: Re: Changing right
hand side of inequalities</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
><br>
> SMPS is silent on these points. So is, for that matter, MPS.
It is a<br>
> fundamental ambiguity built into the standard.<br>
> In the case of the direct interface, nothing needs to be documented
at<br>
> all. It will always do what the user intends.<br>
><br>
<br>
It is ambiguous only if you assume that inequalities are defined with a
lower <br>
and an upper bound (i.e. ranged constraints). Otherwise, the rhs is one<br>
of the two and any request to change the rhs is unambiguous. Since MPS<br>
files require that each inequality is identified as a "<=",
">=" or "="<br>
constraint, I would consider that changing the rhs of such a constraint
<br>
means changing the value of the rhs without changing the type of the <br>
inequality. Only for ranged constraints (that are indeed allowed to appear
<br>
in a MPS file), the request is ambiguous.<br>
<br>
In any case, all this is just bickering. My point is that the actual <br>
implementation of readSmps() could be improved to be able to model<br>
a larger class of problems using core, stoch and time files.<br>
<br>
><br>
> As we have said, SMI does handle inequalities. The example you<br>
> provided is easy and natural to code in the direct interface. The<br>
> issue is how SMPS should handle inequalities in input files.<br>
<br>
I understand that the problem is in readSmps(). I want to improve it,<br>
no work around will make me happy.<br>
<br>
Francois<br>
_______________________________________________<br>
Coin-SMI mailing list<br>
Coin-SMI@list.coin-or.org<br>
http://list.coin-or.org/mailman/listinfo/coin-smi<br>
</tt></font>
<br>