GSOC LP library for Boost
Hello, 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. Thanks for your consideration, Chad
On 28/03/2011 15:25, Chad Seibert wrote:
Hello,
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.
Thanks for your consideration, Chad
Didn't you mention OpenOpt, which is BSD-licensed?
OpenOpt is written in python; I was using it as an example of an LP solver interface. We could use Boost.Python with OpenOpt, but an interface over an interface seems awkward. Something like CORBA could be used, but exposing CORBA to Boost would easily be GSOC project in itself. On Mon, Mar 28, 2011 at 11:28 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 28/03/2011 15:25, Chad Seibert wrote:
Hello,
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.
Thanks for your consideration, Chad
Didn't you mention OpenOpt, which is BSD-licensed?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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@intel.com> 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
Chad Seibert wrote:
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.
You should be able to target stand alone solvers with a file IO interface in addition to library solvers. Writing out the input file format, invoking the external process, waiting for it to finish and then reading its output file back in should be quite easy to do behind the scenes of the adaptor to the generic interface. Regards, Luke
This is a quite reasonable approach, since the MPS file format is a common file format for LP instances. So for library based solvers, I can interface directly with the library, but for standalone solvers, communication with the MPS file format ought to make things much easier. On Mon, Mar 28, 2011 at 1:24 PM, Simonson, Lucanus J < lucanus.j.simonson@intel.com> wrote:
Chad Seibert wrote:
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.
You should be able to target stand alone solvers with a file IO interface in addition to library solvers. Writing out the input file format, invoking the external process, waiting for it to finish and then reading its output file back in should be quite easy to do behind the scenes of the adaptor to the generic interface.
Regards, Luke _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Mar 28, 2011 at 8:48 PM, Chad Seibert <chadjseibert@gmail.com> wrote:
This is a quite reasonable approach, since the MPS file format is a common file format for LP instances. So for library based solvers, I can interface directly with the library, but for standalone solvers, communication with the MPS file format ought to make things much easier.
You may consider to look at the AMPL [1,2] language which is used by many LP (and NLP) solvers Another good LP solver is GNU Linear Programming Toolkit (GLPK) [3] (maybe the problem here is the license which is GPLv3). Finally, on Wikipedia you can find a short comparison of different solvers [4] References: [1] http://www.ampl.com/ [2] http://en.wikipedia.org/wiki/AMPL [3] http://www.gnu.org/software/glpk/ [4] http://en.wikipedia.org/wiki/Linear_programming#Solvers_and_scripting_.28pro... Best, -- Marco
participants (4)
-
Chad Seibert -
Mathias Gaunard -
sguazt -
Simonson, Lucanus J