#18766: Add bindings, MixedIntegerLinearProgram backend to qsopt_ex, a state-of-
the-art exact simplex solver
-------------------------------+------------------------
Reporter: mkoeppe | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: sage-6.8
Component: numerical | Resolution:
Keywords: lp | Merged in:
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: | Stopgaps:
-------------------------------+------------------------
Comment (by mkoeppe):
Replying to [comment:1 dimpase]:
> Perhaps asking the fork author why he went with this version might make
sense. The fork does not look like it is much older than the git repo, and
2.6 was already available for years...
>
> The Python module is actually a Cython module, which is good (but it
does not have the
> full interface, only reading/writing files).
I asked the author of the fork, Jon Lund Steffensen, and he replied as
follows; I'm posting it here with his permission.
It is based on 2.5.10 available here as the "full development code":
http://www.math.uwaterloo.ca/~bico/qsopt/ex/ . To my knowledge this is the
most recent release that includes all code. Here's the NEWS file with a
quick overview of the changes I made: https://github.com/jonls/qsopt-
ex/blob/master/NEWS.md . It seemed to me that the original project was no
longer maintained so I created the fork.
When I started using QSopt_ex as a library I realized that it was not
very usable as a library. The header files were a huge mess of internal
and public interfaces mixed together. The build system was based on custom
Makefiles that didn't quite work on the platforms I wanted to build the
library on. I changed the build system to be based on
autoconf/automake/libtool for better portability. The library had an
external dependency on EGlib, another libsary that appears to be
unmaintained. Since only a tiny subset of EGlib was used by QSopt_ex, I
decided to simply copy the code into QSopt_ex.
The build system used a custom templating system for generating the
code for different numeric types. This was extremely slow because any
change to a source file would cause a regeneration of all of the templated
files. I changed that to a simpler system which also removed the build
dependencies on GNU sed and Exuberant ctags.
I added a Cython-based Python module to access the library, though it
has moved to a separate repository on Github. Lastly, I changed the
logging output to stdout/stderr from the library to go through a logging
function. In an application that was using the library I was writing an
output file to stdout. Since QSopt_ex would simply dump all logging output
to stdout as well it would mess up my output files. I added a function to
the library that allows the user to redirect the logging output to any
destination.''
--
Ticket URL: <http://trac.sagemath.org/ticket/18766#comment:3>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
