Boost logo

Boost :

Subject: Re: [boost] GSOC LP library for Boost
From: Chad Seibert (chadjseibert_at_[hidden])
Date: 2011-03-28 14:16:59


That's exactly what I was thinking, I just wanted to code against lp_solve
to start. But as I finish writing an interface against lp_solve, I can
generalize these interfaces to other libraries. I should be able to code
against the commercial CPLEX solver as well. If there are other libraries
that we wish to support, just let me know.

Thanks,
Chad

On Mon, Mar 28, 2011 at 12:32 PM, Simonson, Lucanus J <
lucanus.j.simonson_at_[hidden]> wrote:

> Chad Seibert wrote:
> > Previously, I mentioned implementing an LP library for Boost.
> > However, there didn't seem to be a consensus on how I should go about
> > it. If we can't agree on a method of attack, then there is no hope
> > for me to get a proposal
> > through the selection committee. So now, I solicit the communities
> > advice on writing a wrapper for lp_solve, an LGPL library that
> > purported to be one of the most stable free LP solvers. Do we care
> > that a dependency is LGPL? I've done my due diligence and there
> > doesn't seem to be a comparable MIT/Boost licensed library.
>
> You should be able to define a generic C++ interface to an LP solver by
> defining what traits an LP solver has then implement adaptors for those
> traits for lp_solve. That way the library doesn't depend on lp_solve
> directly and the user is able to use the same generic C++ interface with the
> LP solver of their choice, including commercial solvers. That is what I
> would to, abstract away the solver so that any solver can be dropped in
> without changing the usage of the solver in client code. That is good
> design whether a particular solver has license issues or not.
>
> Regards,
> Luke
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk