On Mon, Mar 21, 2011 at 3:37 PM, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
Chad Seibert wrote:
Yes, it does. However, it seems inappropriate to write an LP library for Boost that uses LAPACK to do the linear algebra stuff. If we wanted to go down that road, we could just write a wrapper for an existing lp library instead, like what OpenOpt does.
I have to disagree here. We have Boost.MPI, which builds on top of existing MPI implementations instead of trying to reinvent MPI. Now the sandbox numeric bindings project (<http://svn.boost.org/svn/boost/sandbox/numeric_bindings>) probably will never be able to compete with Boost.MPI in terms of perfection, but it seems to be quite usable nevertheless. There are projects like NT2 or eigen, which try to do better/different than BLAS/LAPACK and succeeded more or less. However, I don't see which benefit it would bring if you try to compete with them during a GSOC project.
+1 for this GSOC proposal!! I agree with Thomas. Since the main goal is to build an LP library, I would suggest to Chad to use an already existent linear algebra library and focus its attention to the implementation of LP algorithms. You can always change your underlying implementation with a different one later. For what concerns, linear algebra libraries, currently uBLAS has an LU(P) solver. For what concerns Boost.NumericBindings, it is a valuable friend for integrating uBLAS (and not only it) with LAPACK/BLAS/... However: * Boost.NumericBindings is still not part of Boost. Here the risk is that when reviewing this GSOC for inclusion in Boost, it could not be accepted since it relies in a "beta" library * Use of LAPACK/BLAS/... would add a depedency to a third party libraries. Furthermore such libraries are written in FORTRAN. So it would better to use a C port. So, my opinion is to initially rely as much as possible to uBLAS for handling linear algebra stuff. ;) Best, -- Marco