Technical item 2: SP -- was: Re: [Coin-standards] An argument for public domain modeling infrastructure

[Leonardo B. Lopes]

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