#7012: clean up sage/numerical/mip.pyx
-------------------------+--------------------------------------------------
Reporter: mvngu | Owner: jkantor
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.1.2
Component: numerical | Keywords:
Reviewer: | Author:
Merged: |
-------------------------+--------------------------------------------------
Comment(by mvngu):
Replying to [comment:1 ncohen]:
> Hello !!!
>
> Could I have more information about some points :
>
> 1. Almost all of the docstrings are incorrectly formatted.
>
> Could you tell me in which way ? I am still learning how to write these,
and may have learnt a few things since this patch but I would like to know
what you have in mind.
The Developers' Guide has a section on
[http://www.sagemath.org/doc/developer/conventions.html#documentation-
strings docstring]. You should follow the conventions listed in that
section.
[[BR]][[BR]]
> 1. This module should _definitely_ not be a Cython module as it does not
gain any benefit from Cython. It just makes Sage slower to compile and
things harder to debug.
>
> - I understand that there may be very few reasons left ( now ) for
keeping this as a Cython module. Here is the reason why I built it this
way : initially, I thought the GLPK package would be merged immediately
merged to standard Sage, and the function sending the LP problem to the
solver GLPK ( necessarily written in Cython as it uses C functions ) was
at this time contained in the file numerical.mip. I did not know how to
change this when I learnt GLPK was to be optional for a while, and this is
the reason why I just moved the function solveGLPK to the optional
package. This, though, is way less handy when I need to improve functions
like solveGLPK or solveCBC, as I always need to update the whole package..
I intended to move function solveGLPK to the file numerical.MIP as soon as
GLPK is accepted as a standard spkg.
In light of the recent discussion about making a package standard, a
package that is to be a standard spkg must satisfy at minimum the
following requirements:
1. Build as 32-bit with GCC on SPARC
1. Build as 64-bit with GCC on SPARC
1. Build as 32-bit with Sun's compiler on SPARC
1. Build as 64-bit with Sun's compiler on SPARC
1. Build as 32-bit with GCC on x86
1. Build as 64-bit with GCC on x86_64
1. Build as 32-bit with Sun's compiler on x86
1. Build as 64-bit with Sun's compiler on x86_64
Note that satisfying the first four would likely satisfy the remaining
criteria. It much less work to have GLPK and CBC be optional packages and
hence improve on the MIP module. As far as I can tell, both of these
packages are already optional spkg's and they satisfy the minimum of being
optional packages, namely they build on supported Linux distributions and
Mac OS X 10.5. I have not tried building and using them on OS X 10.6 yet.
But if you have an account on bsd.math which runs OS X 10.6 now, you could
test on that machine. See [http://groups.google.com/group/sage-
devel/browse_thread/thread/15c461b1355a8460/d9660e265ad982d8 here] and
[http://groups.google.com/group/sage-
devel/browse_thread/thread/b54a6b4317add033/bf7224be375df49f here] for the
discussions about making a package standard.
[[BR]][[BR]]
> 1. The optional spkgs should not install modules into the sage.*
namespace (sage.numerical.mipGlpk). This is not the right way to do things
and will eventually break. I think it also makes sense to use (and
contribute to) something like ctypes-glpk to allow greater functionality
and not reinvent the wheel.
>
> I wrote to many people to get informations about how best these things
should be done. I am not happy either with the way it is now... What would
you advise ? I know nothing of ctypes-glpk ! I just visited its front page
and I can only see that it makes C functions available under python, which
Cython can already do.
I have little experience with Cython and much less with maintaining an
optional package. Since I'm busy with release management in the next week
or so, I won't have time to investigate this issue. After finishing the
4.1.2 release, I won't be able to work on anything but my thesis project.
[[BR]][[BR]]
> On top of all this, I have a "personal" request.... I intend to write a
lot of things that will be added to the MIP class ( soon to be
MixedIntegerProgram ), but I initially wrote this class just to write new
Graph-related functions. I have still a lot of patches waiting to be
reviewed/accepted ( #6764 #6763 #6680 #6679 #6765 #6962 ), all using this
class. Each time a modification is brought to the main class MIP, I have
to rewrite patches for all of these tickets to make them coherent with the
"current" state of the MIP Class. Could this ticket wait for these patches
to be merged ? It would be easier, later, to change MIP to
MixedIntegerProgram, isbinary to is_binary, and many other problems/bugs I
already noticed in an unique patch to correct them all at once.... :-)
I think a good way about this is to look through how Simon King produced
his optional p_group_cohomology package. You should ask Simon about his
experiences with writing a self-contained package.
[[BR]][[BR]]
I do intend to clean up the MIP class before releasing Sage 4.1.2. Any
help is appreciated.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7012#comment:2>
Sage <http://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 post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
