[Coin-discuss] RE: Open-source Modeling Languages

Tue Nov 27 12:56:47 EST 2007

Hi Ronald,

I know CVXMOD and the Matlab-based predecessor CVX, and really like
them.  However, their focus is quite specific, namely disciplined
convex programming, where the modelling language can verify the
convexity of the objective function and constraints.  Its ideal for
rapid prototyping of convex models e.g. in Machine Learning.

It does not support discrete/integer optimization nor non-convex
objectives, so its focus is quite different from what most models in
OR (eg. planning models) are concerned with.

Sebastian

On Nov 27, 2007 6:39 PM, Ronald Hochreiter
<ronald.hochreiter at univie.ac.at> wrote:

> I personally like the following rather recent open-source Python-based
> convex optimization modeling tool, which has not been mentioned so far (or
> did I miss something?).
>
> http://cvxmod.net/
>
> which is a modeling layer for:
>
> http://abel.ee.ucla.edu/cvxopt
>
> Regards,
> Ronald
>
> On Di, 27.11.2007, 18:01, coin-discuss-request at list.coin-or.org wrote:
> > Send Coin-discuss mailing list submissions to
> >       coin-discuss at list.coin-or.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >       http://list.coin-or.org/mailman/listinfo/coin-discuss
> > or, via email, send a message with subject or body 'help' to
> >       coin-discuss-request at list.coin-or.org
> >
> > You can reach the person managing the list at
> >       coin-discuss-owner at list.coin-or.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Coin-discuss digest..."
> >
> >
> > Today's Topics:
> >
> >    1. RE: Open-source Modeling Languages (Hart, William E)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 27 Nov 2007 07:12:38 -0700
> > From: "Hart, William E" <wehart at sandia.gov>
> > Subject: RE: [Coin-discuss] Open-source Modeling Languages
> > To: "Discussions about open source software for Operations Research"
> >       <coin-discuss at list.coin-or.org>
> > Cc: maj at northwestern.edu, bradbell at seanet.com,
> >       h-sheng at northwestern.edu
> > Message-ID:
> >       <54246FD42F98AA4389A44EA140FF5F9704F9794F at ES21SNLNT.srn.sandia.gov>
> > Content-Type: text/plain; charset=us-ascii
>
> >
> >
> > Although most of this thread has focused on licensing issues, I wanted
> > to second Sebastian's observation that there is real utility in an
> > open-source modeling language.  Even in my pseudo-industrial role at
> > Sandia, this frequently comes up; customers want the features of a
> > modeling language, but they are often scared-off by the licensing
> > costs/requirements.
> >
> > I am hoping that an alternative to FlopC++ will be available shortly.
> > Leo Lopez and I have independently developed Python modeling tools.
> > These leverage Python's expressive scripting language to support an
> > object-oriented semantics that is reasonably natural (I won't claim it's
> > as clean as something like AMPL).  As with FlopC++, the user can
> > leverage the flexibility of a complete programming language to develop
> > complex models.
> >
> > I was personally motivated to protype this capability in Python because
> > (a) I have become frustrated with the limitations of AMPL (the
> > commercial modeling tool that we have available within Sandia), (b) my
> > customers don't want to pay for a commercial modeling tool anyway, and
> > (c) developing this capability in a mature scripting language freed me
> > from much of the grungy parts of managing a new modeling language.  [OK,
> > (d) I am quite familiar with Python, which has a very clean syntax that
> > works well in this context.] So, while this doesn't provide a customized
> > syntax for optimization, it does provide a flexible basis for building
> > up optimization modeling capabilities.
> >
> > Leo and I are working on legal issues related to the release of our
> > software, the merge of these capabilities into a single Python
> > framework, and the potential integration of it into COIN-OR. Hopefully,
> > the code will be available within the next few months...
> >
> > --Bill
> >
> >> -----Original Message-----
> >> From: coin-discuss-bounces at list.coin-or.org
> >> [mailto:coin-discuss-bounces at list.coin-or.org] On Behalf Of
> >> Sebastian Nowozin
> >> Sent: Tuesday, November 20, 2007 10:21 AM
> >> To: Discussions about open source software for Operations Research
> >> Cc: maj at northwestern.edu; bradbell at seanet.com;
> >> h-sheng at northwestern.edu
> >> Subject: Re: [Coin-discuss] Open-source Modeling Languages
> >>
> >> Hello,
> >>
> >> On Nov 20, 2007 5:35 PM, Kipp Martin
> >> <kipp.martin at chicagogsb.edu> wrote:
> >>
> >> > > [...]
> >> > > The OS folks can correct me if I'm wrong, but it seems
> >> that the XML
> >> > > file acts more like the .nl file that AMPL produces (as an
> >> > > intermediate format between AMPL and a solver) than an
> >> MPS file. I
> >> > > doubt most people have ever looked at a .nl file. It is produced
> >> > > transparently by a higher level layer and they never see it.
> >>
> >> > Exactly! OSiL is a representation for an instance as opposed to the
> >> > higher level model.  We don't expect people to really look
> >> at an OSiL
> >> > file. But if they did I think it would be a lot more
> >> transparent then
> >> > nl or mps.
> >>
> >> But then, the question of a natural and reasonably powerful
> >> open-source modeling language becomes more pressing; having
> >> nice intermediate problem format like OSiL/OSrL and cutting
> >> edge solvers like Ipopt, CBC or Bonmin is not going to
> >> benefit a lot of users if they cannot develop good models
> >> quickly in a language suited to the task, at least not the
> >> non-programming users.
> >>
> >> I have taken a look at FlopC++ and it looks really nice,
> >> especially for going from a rapid prototype directly into a
> >> working component of a software; but I find it hard to
> >> imagine it as standard form to exchange/discuss/publish
> >> models in due to the compilation dependency.
> >>
> >> (As one being not involved at all with COIN-OR and only from
> >> a user perspective, so I'm sorry if I trip on anyone's toe.)
> >> If one would want to fill this gap, extending FlopC++ to
> >> support nonlinear optimization might be one way to go, as it
> >> is already well integrated with COIN.  Asking kindly the
> >> author of GLPK for relicensing of the MathProg part of GLPK
> >> under the CPL and making it a larger subset of AMPL would be
> >> another option; if the latter is done within OS, all solvers
> >> who could read OSiL would profit from this in the future.
> >>
> >> Sebastian
> >> _______________________________________________
> >> Coin-discuss mailing list
> >> Coin-discuss at list.coin-or.org
> >> http://list.coin-or.org/mailman/listinfo/coin-discuss
> >>
> >>
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > Coin-discuss mailing list
> > Coin-discuss at list.coin-or.org
> > http://list.coin-or.org/mailman/listinfo/coin-discuss
> >
> >
> > End of Coin-discuss Digest, Vol 37, Issue 16
> > ********************************************
>
> >
> >
>
>
> _______________________________________________
> Coin-discuss mailing list
> Coin-discuss at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-discuss
>