Integration -- was: Re: [Coin-standards] minutes / strategy

[Irv Lustig]

Leo:

At 12:11 PM 4/12/02 -0500, Leonardo B. Lopes wrote:
>Basically, I don't believe that anyone will ever devolep a modeling tool
>that will be a magic bullet. There are two reasons for that: first,
>modeling is done by human beings, and human beings have too many
>subjective preferences, biases, attachments, and political interests;
>second, the character of the problems being modeled is just too wide; the
>tradeoffs required from one application sometimes exclude other
>applications. Furthermore, this pattern of multiple modeling interfaces
>has been true in every other CS application, with the (possible) exception
>of database systems where SQL is king.

I still don't see why the "industry" couldn't agree on a modeling language 
that would cover the majority of industrial optimization problems.  In 
essence, I'm suggesting that we come up with an SQL for optimization.


>Of course we know that clients don't want to learn more than one tool (or
>even a single one for that matter), which means that the fact that more
>than one tool is being used will have to be hidden from them. This implies
>that different modeling tools, data management tools, and maybe solvers or
>things in between (i.e. a decomposition manager) will need to collaborate.

I agree.

>Many times, they will collaborate at the model level. That is where we
>agree (I hope).

Yup.

>  But they will sometimes also need to collaborate at the
>instance level. Doing that today is way too hard to be practical, but it
>doesn't have to be.

I'm not convinced that the tools need to collaborate at the instance level. 
The only tools that need that collaboration are modeling languages and solvers.

>Yes, that is the disconnect. See above. OTOH, if all the standard did were
>benefit algorithm designers, that in itself would be pretty good.

And since those algorithm designers are primarily in academia, you're back 
to creating a standard that doesn't have an impact in industry.

>Yes way. Maybe not today, and maybe not for every problem. But in enough
>special cases to be worth paying attention, that would be feasible, even
>if the instances were that large, which they wouldn't be. And even on my
>DSL line, a gigabite can be transferred in just under 3.5 hours, which is
>reasonable for some applications.

You're assuming that we can't solve that problem in 3.5 hours.  We receive 
instances from customers (compressed MPS files) that are a few hundred 
megabytes, and we solve them in an hour.  The customers wouldn't want to 
wait for the transmission time if the optimizer were server-based.

>  Plus, I think the more representative
>case is that in which the user interfaces some modeling tool, which uses a
>bunch of other modeling tools or solvers over some web services
>architecture like .net or equivalent.

I don't see solvers sitting in web services, because the data transmission 
requirements will be too high.

Web services will be good for transactional applications (verify your 
identity, credit card, get a map, get the weather, etc.).  Optimization is 
an analytical application requiring lots of data to produce an answer.  The 
communication requirements will be too high.  And the analysts I've talked 
to agree with this.

>I think vendors benefit if we accept the argument that having a better
>standard makes it easier to develop better, modular, modeling tools,
>and/or the argument that a new standard helps research.

So the benefit could be long term.  I might be willing to accept that.

>  What that
>ultimately does (maybe not this fiscal quarter) is make optimization more
>accessible and more prevalent, consequently creating opportunities for new
>revenue streams in places where there weren't any.

I think this last sentence is a stretch.

         -Irv