[Coin-standards] INFORMS / directions

[Laurent Perron]

On Wed, 2002-10-16 at 23:20, Leonardo B Lopes wrote:
> Dear Colleagues,
> 
>   INFORMS San Jose would be a great opportunity to advance some of our
> technical and business issues. It would be even better if by the time we
> got there we had a sketch of a framework for the work ahead. I am going
> to draw my own views of what that should be, and hopefully others can
> chip in.
> 
>   Quick Summary:
> 
>   * We are trying to accomplish an unified mechanism for communicating
> *instances* (not models) of mathematical programs, be they linear, 
> non-linear, stochastic, overconstrained or complementarity programs.
> 
>   Points:
> 
>   * There are two parallel tracks: creating an XML-based representation,
> and formalizing the MPS and SMPS standards.
> 
>   * The main benefit of our success is to simplify the connection between
> solvers and modeling environments. If we succeed, then solver authors
> will only need to write one driver to give all modeling environments
> access to it. The same will be true for modeling environment authors.
> Also, writing these drivers will be much easier than it is today, due to
> libraries that manipulate XML and libraries we will produce on top of them.
> 
>   * Ancillary benefits include: connectivity transparency; easier access 
> to other mathematical / statistical / database / report generator / 
> etc... software, including presolvers or automatic differentiators.
> 
>   Deliverables:
> 
>   * For the XML-based standard:
>    * A DTD and/or schema formally describing what the data
>    being converted looks like;
>    * A library that makes writing drivers easy, based on
>    OSI, or to be added to OSI;
>    * A test suite and a certification library of problems;
> 
>   * For the MPS/SMPS standard:
>    * A formal document specifying the standard;
>    * A test suite and a certification library of problems;
> 
>   What is and isn't expected of *you*:
> 
>   * Share your experience, knowledge, and brainpower. Some of the 
> comments made in the list before summer were quite interesting. Concrete
> proposals (at least for specific sections) are even better. I have
> contributed a SNLP DTD (which I have revised a couple of times). ILOG
> folks mentioned something about a CLP DTD.
> 
>   * Illustrative examples in your field of expertise, or in your
> application area.
> 
>   * We DO NOT expect you to produce large amounts of coding. We are all 
> too busy to do that. But we have commitments from myself, John Forrest, 
> Bob Fourer, and Gus Gassman, that once we have good specifications, we
> will have working software.
> 
>   What we already accomplished:
> 
>   * Rows and Columns must be complex objects, so that they can be used by
> CLP programs correctly. I have incorporated that into the most recent
> proposal.
> 
>   * There needs to be an efficient algebra for manipulating similar
> matrices, for SLP problems. That is also incorporated into the proposal.
> 
>   What we need to decide / accomplish next:
> 
>   * Do we need a sufficiently general approach for including
> distribution-based problems? Is the SMPS approach to these problems
> sufficient? Would someone like to contribute a design that is compatible
> with the current proposal, or modify it in a suitable way?
> 
>   * Do we have a CLP proposal? If not, we should draft one.

Hello, 

First of all, I would like to apologize about my lack on visible work on
this subject.

Let me present myself, I am Laurent Perron and I am project leader of
ILOG Solver and ILOG Concert. ILOG Concert is a common modeling API
shared by ILOG Cplex and ILOG Solver (our CP engine).

The main idea behind an XML format suitable for CLP or CP is about
expressiveness. For instance, we have some "logical" constraint that we
use to model our problem. Such logical constraints are "all different",
"sequence". They may be very difficult to linearize, or impossible to
linearize. They may also have different linearizations that adapted to
different situations.

Therefore, the implication is that for each of these logical
constraints, there will be a special xml tag for them.

Please note that our CP engine deals with other kind of basic objects
(integer set variable, integer bag (or multi-set) variables). There are
also extensions to deal with scheduling, dispatching and routing,
configuration... Each of these extensions introduce new basic objects
and thus new XML tags.

We have also developed a internal XML layer to save out models. This
layer is mapped quite directly from our Concert layer. I think it would
be a good idea to show some samples of these generated XML to compare
with this standardization effort (that we want to support in addition to
this simple XML format).

--Laurent Perron




> 
>   * I have not thought about complementarity. How should we represent 
> that class of problems? Suggestions? How about MDPs? Distributions 
> problems? etc...?
> 
>   * Other items?
> 
> 
> Thanks,
> Leo.
> --
> =======================================================================
> Leonardo B. Lopes                                      leo at iems.nwu.edu
> Ph.D. Candidate                                           (847)491-8470
> IEMS - Northwestern University             http://www.iems.nwu.edu/~leo
> 
> 
> 
> 
> _______________________________________________
> Coin-standards mailing list
> Coin-standards at www-124.ibm.com
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/coin-standards
>