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

Leonardo B. Lopes leo at iems.nwu.edu
Fri Apr 12 13:11:11 EDT 2002


On Thu, 11 Apr 2002, Irv Lustig wrote:

> I don't think the programs need to talk *optimization* to each other.  They 
> need to have better ways of passing data to each other.  The optimization 
> tool (like a modeling language) can take this data and create the 
> optimization instance.

Maybe this makes obvious the fundamental distinctions between our
assumptions. Your second sentence would be the same as mine, except that
the subject would be plural: The optimization tools (like modeling
languages) can take this data and create the optimization instance.

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.

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.
Many times, they will collaborate at the model level. That is where we
agree (I hope). 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.

> 
> All the benefits above seem to benefit algorithm designers.  Maybe this is 
> where the disconnect is happening?
> 

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

> >Having it be xml based also helps with network >communication,
> 
> Send your gigabyte instance via the network?  No way.  :->
> 

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. 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'm not sure I agree with you here that as the tool vendor, we benefit by 
> having a new standard.
> 

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. 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.

> >By the way, I haven't had the opportunity to thank you (Irv) for your
> >insights. I've been learning a lot and changing a bit my assumptions about
> >some of these issues. I hope you're not done, although I'm anxious to get
> >technical soon. I'll try to do that next...
> 
> It's an interesting discussion.  I hope I'm not dampening your enthusiasm 
> by giving you my thoughts from the trenches.
> 

No, not at all Irv. Thoughts from the trenches are very valuable, and
unfortunately I don't have many of those yet. I wish we agreed more often,
but I can't say I expected us to. Our goals and rewards are different, and
that makes our rose colored glasses have different shades :). In addition,
I (or you, or us both) could be mistaken about some things. This is the
best time to figure them out...

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





More information about the Coin-standards mailing list