Technical item 2: SP -- was: Re: [Coin-standards] An argument
for public domain modeling infrastructure
Leonardo B. Lopes
leo at iems.nwu.edu
Mon Apr 15 12:24:43 EDT 2002
I think an SMPS reader **and writer** api is a good idea. In fact I
thought Dr. Gassmann was going to propose this in this same list. I
currently have an SMPS rw api written in a mixture of python and sql,
which is fine for research purposes, but has very little error checking,
amongst other shortcomings. I think I should be able to conribute that.
I'd be willing to contribute more, but not to lead that project. I think
Gassmann and/or you are probably the right people for that.
The other thing is: ***I am not proposing a modeling standard***. What I
propose is similar to MPS/SMPS/SIF/NL. And frankly, the easiest way to
write an SMPS writer is to write an XML representation first.
On Mon, 15 Apr 2002, Alan King wrote:
>
> Hi Leo,
>
> As I read your reaction to my comments, I realize that my irritation at the
> lack of progress in building modeling infrastructure for stochastic
> programming perhaps distorts what you are hearing from me.
>
> Let me be straightforward. I am interested in getting effort going that
> will result in some interesting developments in stochastic programming
> modeling software. I believe (having tried it) that working with
> commercial interests is not the way to go. Progress is too slow. So I
> want to invest in a public domain effort.
>
> John Forrest has just contributed an open source MPS file reader to the OSI
> package on COIN. I would like to do the same for a Stochastic MPS file
> reader. (Of course, there is a working SMPS reader in OSLSE. But this
> connects to the structures of the OSLSE package, which are byzantine, to
> say the least.)
>
> I think you should be interested in this, because if your modeling standard
> supports stochastic programming it certainly should be able to implement
> SMPS. It would be a good test case for your proposals.
>
> Now, to be truly open source there has to be a community. So, are you (or
> anyone out there) interested in developing an open source SMPS file reader?
> If so, write me a note and lets get started.
>
> Best wishes,
> Alan
>
> Alan King
> http://www.research.ibm.com/people/k/kingaj/
> Mathematical Sciences Department
> IBM Thomas J. Watson Research Center
> (914) 945-1236, 8-862-1236
>
>
>
> "Leonardo B.
> Lopes" To: Alan King/Watson/IBM at IBMUS
> <leo at iems.nwu.edu cc: coin-standards at www-124.southbury.usf.ibm.com
> > Subject: Re: Technical item 2: SP -- was: Re: [Coin-standards] An argument for public
> domain modeling infrastructure
> 04/12/2002 02:21
> PM
>
>
>
>
>
> Hi, Dr. King,
>
> Sorry. The Miami proposal is on the standards website:
>
> http://senna.iems.nwu.edu/xml
>
> There are a few changes I made when I created the ampl driver, about a
> month ago. The most significant ones are the expression of bounds and the
> stage in which T is expressed (now t+1, which makes a lot more sense).
>
> >
> > Multiple Core files: In principle there should be no difficulty in
> stating
> > that the SMPS standard should allow more than one core file. So far no
> > practical solution has been offered. (If there is one, please send it to
> > me.)
>
> Gassmann's SMPS extension actually has a similar mechanism, he calls
> nodes. It is more fair in fact to say that my mechanism is an intellectual
> child of Gassmann's nodes than an SMPS with multiple cores. Basically,
> every matrix has a (possibly different) parent
>
> > Along those lines let me share one of the more successful operating
> > principles I learned at IBM: "keep it simple". (This is in a sense what
> > you are hearing from Irv. Why go beyond MPS if no-one is asking for it?)
>
> That's interesting. At the Miami conference, there were a lot of people
> asking for it, both in industry and in research. The same thing was true
> at the SP conference, where this all started, remember? I certainly feel
> the need for it. Also, I think the technology around us is changing, and
> that creates new opportunities. The need for the new standard comes as a
> tool to support forays into these new opportunities. Nothing new is really
> warranted when all that needs to be done is what was already being done.
> Maybe I'm just too optimistic about things, but I think we ought to be
> doing a lot more than we do. This is just one of many tools needed to
> accomplish some of those things.
>
> > With "simple" as a by-word, you can see why SMPS evolved along the lines
> > that it did: one core file, scenarios format, library-style interfaces.
> > Anything else requires so much more effort. Every choice given the user
> > requires documentation, support, hassles when things change or break,
> etc,
> > etc.
>
> Some aspects of the proposals will be thrown away because the benefits
> don't warrant the complications, and some won't. Some others may be added.
> Let's see which are most important. It is important to realize that many
> of the complications can be hidden behind the DOM, so a little bit more
> effort now saves a lot more effort later . I've asked myself the
> simplicity question many times. The answer I most often come up with is
> that we can do better. We have both the intellectual and technical ability
> to do things better, even if they are more complicated, especially in a
> project like this, which will be used by a lot of people. So I take better
> over simple sometimes. Auditing that it is one of the many contributions I
> like to get from you, Irv, Bjarni, or others who haven't spoken yet.
>
> Cheers,
> Leo.
>
> ========================================================================
> Leonardo B. Lopes leo at iems.nwu.edu
> Ph.D. Student (847)491-8470
> IEMS - Northwestern University http://www.iems.nwu.edu/~leo
>
>
>
>
>
>
========================================================================
Leonardo B. Lopes leo at iems.nwu.edu
Ph.D. Student (847)491-8470
IEMS - Northwestern University http://www.iems.nwu.edu/~leo
More information about the Coin-standards
mailing list