From fmargot at andrew.cmu.edu Fri May 20 12:00:46 2005 From: fmargot at andrew.cmu.edu (Francois Margot) Date: Fri, 20 May 2005 12:00:46 -0400 (EDT) Subject: [Coin-SMI] Changing right hand side of inequalities Message-ID: I am trying to change the right hand side of inequalities in the .stoch file. When working with equalities, everything works as expected, but with inequalities, instead of changing the rhs, the code creates a ranged constraint. I list below the three input files creating the problem. The code we use is basically the following: smi.readSmps(bug); OsiClpSolverInterface *clp = new OsiClpSolverInterface(); smi.setOsiSolverHandle(*clp); OsiSolverInterface *osiStoch =smi.loadOsiSolverData(); osiStoch->writeMps("bug"); Using the following files: ---------------------------------------------------------- bug.core file: NAME BUG ROWS N obj G C0 G C1 G C2 G C3 COLUMNS x01 obj 1 x01 C3 1 x01 C1 1 x01 C0 1 x02 obj 1 x02 C2 1 x02 C1 1 x02 C0 1 x03 obj 1 x03 C3 1 x03 C2 1 x03 C0 1 x04 obj 0.5 x04 C3 1 x04 C1 1 x05 obj 0.5 x05 C2 1 x05 C1 1 x06 obj 0.5 x06 C3 1 x06 C2 1 RHS RHS C0 0 RHS C1 1 RHS C2 1 RHS C3 1 ENDATA ---------------------------------------------------------- bug.stoch file: NAME BUG SCENARIOS DISCRETE REPLACE SC SCEN01 ROOT 0.500 STG02 RHS C1 1.000 RHS C2 1.000 RHS C3 0.000 SC SCEN02 ROOT 0.500 STG02 RHS C1 0.000 RHS C2 1.000 RHS C3 0.000 ENDATA ----------------------------------------------------------- bug.time: TIME BUG PERIODS LP x01 C0 STG01 x04 C1 STG02 ENDATA ----------------------------------------------------------- bug.mps file obtained: NAME BLANK ROWS N OBJROW G R0000000 E R0000001 E R0000002 L R0000003 L R0000004 E R0000005 L R0000006 COLUMNS C0000000 OBJROW 1. R0000000 1. C0000000 R0000001 1. R0000003 1. C0000000 R0000004 1. R0000006 1. C0000001 OBJROW 1. R0000000 1. C0000001 R0000001 1. R0000002 1. C0000001 R0000004 1. R0000005 1. C0000002 OBJROW 1. R0000000 1. C0000002 R0000002 1. R0000003 1. C0000002 R0000005 1. R0000006 1. C0000003 OBJROW 0.25 R0000001 1. C0000003 R0000003 1. C0000004 OBJROW 0.25 R0000001 1. C0000004 R0000002 1. C0000005 OBJROW 0.25 R0000002 1. C0000005 R0000003 1. C0000006 OBJROW 0.25 R0000004 1. C0000006 R0000006 1. C0000007 OBJROW 0.25 R0000004 1. C0000007 R0000005 1. C0000008 OBJROW 0.25 R0000005 1. C0000008 R0000006 1. RHS RHS R0000001 1. R0000002 1. RHS R0000005 1. RANGES RANGE R0000003 -1. R0000004 -1. RANGE R0000006 -1. ENDATA ------------------------------------------------------------------ Note that R0000001, R0000002, and R0000005 become equalities (instead of >= 1) and R0000003, R0000004, and R0000006 become ranged constraints (instead of >= 0). If the proper way to change the rhs of inequalities is something else, I would appreciate a simple example. Francois From kingaj at us.ibm.com Fri May 27 20:19:53 2005 From: kingaj at us.ibm.com (Alan King) Date: Fri, 27 May 2005 20:19:53 -0400 Subject: [Coin-SMI] Changing right hand side of inequalities In-Reply-To: Message-ID: That's right: SmiScnModel::readSmps() will not read all bounds formats correctly. SmiScnModel seems to be working fine, though. So its better to use the "direct interface pattern". I have uploaded the nice Bug example using this pattern into Coin/Examples/Stoch/stoch.cpp. Thanks Francois! Alan King Francois Margot Sent by: coin-smi-bounces at list.coin-or.org 05/20/2005 12:00 PM To coin-smi at list.coin-or.org cc Subject [Coin-SMI] Changing right hand side of inequalities I am trying to change the right hand side of inequalities in the .stoch file. When working with equalities, everything works as expected, but with inequalities, instead of changing the rhs, the code creates a ranged constraint. I list below the three input files creating the problem. The code we use is basically the following: smi.readSmps(bug); OsiClpSolverInterface *clp = new OsiClpSolverInterface(); smi.setOsiSolverHandle(*clp); OsiSolverInterface *osiStoch =smi.loadOsiSolverData(); osiStoch->writeMps("bug"); Using the following files: ---------------------------------------------------------- bug.core file: NAME BUG ROWS N obj G C0 G C1 G C2 G C3 COLUMNS x01 obj 1 x01 C3 1 x01 C1 1 x01 C0 1 x02 obj 1 x02 C2 1 x02 C1 1 x02 C0 1 x03 obj 1 x03 C3 1 x03 C2 1 x03 C0 1 x04 obj 0.5 x04 C3 1 x04 C1 1 x05 obj 0.5 x05 C2 1 x05 C1 1 x06 obj 0.5 x06 C3 1 x06 C2 1 RHS RHS C0 0 RHS C1 1 RHS C2 1 RHS C3 1 ENDATA ---------------------------------------------------------- bug.stoch file: NAME BUG SCENARIOS DISCRETE REPLACE SC SCEN01 ROOT 0.500 STG02 RHS C1 1.000 RHS C2 1.000 RHS C3 0.000 SC SCEN02 ROOT 0.500 STG02 RHS C1 0.000 RHS C2 1.000 RHS C3 0.000 ENDATA ----------------------------------------------------------- bug.time: TIME BUG PERIODS LP x01 C0 STG01 x04 C1 STG02 ENDATA ----------------------------------------------------------- bug.mps file obtained: NAME BLANK ROWS N OBJROW G R0000000 E R0000001 E R0000002 L R0000003 L R0000004 E R0000005 L R0000006 COLUMNS C0000000 OBJROW 1. R0000000 1. C0000000 R0000001 1. R0000003 1. C0000000 R0000004 1. R0000006 1. C0000001 OBJROW 1. R0000000 1. C0000001 R0000001 1. R0000002 1. C0000001 R0000004 1. R0000005 1. C0000002 OBJROW 1. R0000000 1. C0000002 R0000002 1. R0000003 1. C0000002 R0000005 1. R0000006 1. C0000003 OBJROW 0.25 R0000001 1. C0000003 R0000003 1. C0000004 OBJROW 0.25 R0000001 1. C0000004 R0000002 1. C0000005 OBJROW 0.25 R0000002 1. C0000005 R0000003 1. C0000006 OBJROW 0.25 R0000004 1. C0000006 R0000006 1. C0000007 OBJROW 0.25 R0000004 1. C0000007 R0000005 1. C0000008 OBJROW 0.25 R0000005 1. C0000008 R0000006 1. RHS RHS R0000001 1. R0000002 1. RHS R0000005 1. RANGES RANGE R0000003 -1. R0000004 -1. RANGE R0000006 -1. ENDATA ------------------------------------------------------------------ Note that R0000001, R0000002, and R0000005 become equalities (instead of >= 1) and R0000003, R0000004, and R0000006 become ranged constraints (instead of >= 0). If the proper way to change the rhs of inequalities is something else, I would appreciate a simple example. Francois _______________________________________________ Coin-SMI mailing list Coin-SMI at list.coin-or.org http://list.coin-or.org/mailman/listinfo/coin-smi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.coin-or.org/pipermail/smi/attachments/20050527/e38e47f6/attachment.html From fmargot at andrew.cmu.edu Sat May 28 10:07:00 2005 From: fmargot at andrew.cmu.edu (Francois Margot) Date: Sat, 28 May 2005 10:07:00 -0400 (EDT) Subject: [Coin-SMI] Re: Re: Changing right hand side of inequalities In-Reply-To: <200505281600.j4SG0XBm007063@iol-e.informs.org> References: <200505281600.j4SG0XBm007063@iol-e.informs.org> Message-ID: > That's right: SmiScnModel::readSmps() will not read all bounds formats > correctly. SmiScnModel seems to be working fine, though. > > So its better to use the "direct interface pattern". I have uploaded the > nice Bug example using this pattern into Coin/Examples/Stoch/stoch.cpp. > I think this should be fixed, as reading the .stoch, .core and .time files is the simplest way to load a problem. Otherwise, it is impossible to write code that will work on examples provided by a non technical savvy user, as everything has to be coded and recompiled when using the "direct interface pattern". Francois From kingaj at us.ibm.com Sun May 29 03:30:07 2005 From: kingaj at us.ibm.com (Alan King) Date: Sun, 29 May 2005 03:30:07 -0400 Subject: [Coin-SMI] Re: Re: Changing right hand side of inequalities In-Reply-To: Message-ID: 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 Alan Francois Margot Sent by: coin-smi-bounces at list.coin-or.org 05/28/2005 10:07 AM To coin-smi at list.coin-or.org cc Subject [Coin-SMI] Re: Re: Changing right hand side of inequalities > That's right: SmiScnModel::readSmps() will not read all bounds formats > correctly. SmiScnModel seems to be working fine, though. > > So its better to use the "direct interface pattern". I have uploaded the > nice Bug example using this pattern into Coin/Examples/Stoch/stoch.cpp. > I think this should be fixed, as reading the .stoch, .core and .time files is the simplest way to load a problem. Otherwise, it is impossible to write code that will work on examples provided by a non technical savvy user, as everything has to be coded and recompiled when using the "direct interface pattern". Francois _______________________________________________ Coin-SMI mailing list Coin-SMI at list.coin-or.org http://list.coin-or.org/mailman/listinfo/coin-smi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://list.coin-or.org/pipermail/smi/attachments/20050529/3c0970cd/attachment.html From fmargot at andrew.cmu.edu Sun May 29 02:49:31 2005 From: fmargot at andrew.cmu.edu (Francois Margot) Date: Sun, 29 May 2005 02:49:31 -0400 (EDT) Subject: [Coin-SMI] Re: Re: Changing right hand side of inequalities In-Reply-To: References: Message-ID: 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 From ajking at mac.com Sun May 29 08:42:48 2005 From: ajking at mac.com (ajking at mac.com) Date: Sun, 29 May 2005 08:42:48 -0400 Subject: [Coin-SMI] Re: Re: Changing right hand side of inequalities In-Reply-To: References: Message-ID: <9925361d450440c38ec1cc81ef347cdf@mac.com> 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. I use the smps cases for regression testing, mainly. 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 From fmargot at andrew.cmu.edu Sun May 29 08:08:34 2005 From: fmargot at andrew.cmu.edu (Francois Margot) Date: Sun, 29 May 2005 08:08:34 -0400 (EDT) Subject: [Coin-SMI] Re: Re: Changing right hand side of inequalities In-Reply-To: <9925361d450440c38ec1cc81ef347cdf@mac.com> References: <9925361d450440c38ec1cc81ef347cdf@mac.com> Message-ID: 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 > > > From ajking at mac.com Mon May 30 04:32:43 2005 From: ajking at mac.com (ajking at mac.com) Date: Mon, 30 May 2005 04:32:43 -0400 Subject: [Coin-SMI] Re: Re: Changing right hand side of inequalities In-Reply-To: References: <9925361d450440c38ec1cc81ef347cdf@mac.com> Message-ID: <52b728fda2fff306db97d1895c896e03@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 From fmargot at andrew.cmu.edu Mon May 30 09:59:03 2005 From: fmargot at andrew.cmu.edu (Francois Margot) Date: Mon, 30 May 2005 09:59:03 -0400 (EDT) Subject: [Coin-SMI] Re: Re: Changing right hand side of inequalities In-Reply-To: <200505301600.j4UG0RoT003663@iol-e.informs.org> References: <200505301600.j4UG0RoT003663@iol-e.informs.org> Message-ID: > > 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