Got it ! I knew nothing about all this, sorry :-)
I was just growing impatient because I only wrote the interface between GLPK/Coin and Sage to add new functions to the Graph class, whose docstrings I am currently writing... I already wrote : def min_dominating_set(g, value_only=False): def min_independant_dominating_set(g, value_only=False): def min_vertex_cover(g,value_only=False): def max_matching(g,value_only=False, use_edge_labels=True): def max_flow(g,x,y,value_only=True,integer=False, use_edge_labels=True): def min_edge_cut(g,s,t,value_only=True,use_edge_labels=True): def min_vertex_cut(g,s,t,value_only=True): def edge_connectivity(g,value_only=True,use_edge_labels=True): def vertex_connectivity(g,value_only=True): def coloring(g,k=None): and I think they may be pretty useful in the standard Sage.. ( it is pretty easy to write them through LP, none of them is longer than 30 lines, but try to do it without... :-) ) Robert : I'll give a look to pymprog immediately, just to see what I could add to what is already written, or if they are just ages in advance.. But we had to write some meta-LP class to be able to use indifferently GLPK, Coin, and CPLEX anyway... ;-) Thank you all again ! Nathann On Aug 1, 3:24 pm, David Joyner <[email protected]> wrote: > I think Nathann Cohen has done a very valuable service with the GLPK and > COIN-OR-related packages. > > That said, I have a "point of order" question. Is is true or false that the > process for a package to become standard we > (1) use trac to do nomination, testing, and acceptance as an optional > package, > (2) someone (William say) posts the spkg > tohttp://www.sagemath.org/packages/optional/, > (3) after a period of a few months, voting is done for making it standard. > > In any case, I vote +1 for Nathann's GLPK spkg being moved to optional > and the currently posted GLPK spkg on experimental removed, with the > idea that it be proposed for inclusion as a standard package. > > If the above process is correct then there is nothing more to say. > If not, I think someone (not me) look into this PyGLPK (I am > not an OR person and have never heard of this before). By > compare, I mean, look at the license, compare Nathann's wrappers and > docstrings to PyGLPK's, etc. Maybe there are other wrappers > on the internet (I have not done a google search, just mentioning > possibilities here.) > > On Sat, Aug 1, 2009 at 8:55 AM, Robert<[email protected]> wrote: > > > I'd like LPs, too, of course. > > > By the way, do you know of the projecthttp://pymprog.sourceforge.net/ > > that wraps GLPK with it's modelling language in python? Using PyGLPK, > > as an additional layer, I'm pretty sure there is some relevant code > > there. > > > On Aug 1, 12:46 pm, Carlo Hamalainen <[email protected]> > > wrote: > >> On Sat, Aug 1, 2009 at 9:41 AM, Nathann Cohen<[email protected]> > >> wrote: > >> > Are you interested by LP features in Sage with GLPK as the native > >> > solver ? ( The others would have to be optional packages but we > >> > thought it would be smart to have a native one ). > > >> Yes, especially if it can be used to speed up the graph colouring code > >> in some cases (at the moment it uses my C++ dlx solver but I'm sure > >> that LP etc could be useful in some other cases). > > >> -- > >> Carlo Hamalainenhttp://carlo-hamalainen.net --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
