#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 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.
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.
1. Some of the naming conventions do not match Sage's conventions.
(isbinary vs. is_binary). Also, names like the more explicit
MixedIntegerProgram? are preferred over the shortened MIP.
- I quite agree
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.
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.... :-)
Thank you a lot for your interest, though :-)
Nathann
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7012#comment:1>
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
-~----------~----~----~----~------~----~------~--~---
