Hi Nathann! I found that when installing cbc I had to add "#include <cstdlib>" to CbcEventHandler.cpp, otherwise I got compilation errors about NULL not being defined. I'm using gcc 4.6.1. The glpk install went smoothly. I noticed on your tutorial you also mention IBM's CPLEX. Are the sage wrappers for it open source?
In terms of parallel algorithms, I'm really not sure what would be appropriate at this point. I thought there might be some genetic algorithms that could take advantage of parallelism and possibly also ways to parallelize the objective functions. At the moment I'm mainly looking into the background on various logistic and transportation problems. Chris On Sat, Mar 17, 2012 at 10:11 AM, Nathann Cohen <[email protected]> wrote: > Hellooooooooooooooooooooooooooooo !!! > > >> Thanks! I spent some time with the graph and milp support today, and it's >> exactly what I was looking for. > > Glad to hear it ! :-) > > >> Do you have an idea of how the current >> implementations scale with the size of the graph? > > Oh. Well, I do not use LP to solve problems on huge graphs. But I do solve > huge LP for small graphs :-) > > >> Any interest in adding >> support for parallel algorithms? > > Oh. Well, I guess no one -- least of all me -- would mind. Which kind of > algorithms would you have in mind ? :-) > > >> I'm interested in the underlying data >> structures for the graphs and how the objective function expressions are >> being passed to the low level implementations (e.g. Coin) > > Well, I hope that I did the job well on this respect. We use all the solvers > through their C/C++ Api, and at this level the functions are given as > efficiently a the solvers let us do it, that is something like 2 C arrays > (the indices of the variables which have a nonzero coefficient, and the list > of coefficients), or through methods for sparse vectors (I think only CBC > does that). Of course, when you use the LP classes at Python level, we first > have to do some Python operations to convert the information you give to the > format the solvers expect, but at least we have control on all levels down > to C. So we are more or less free to do as we want :-) > > One thing to note : when you have to sum MANY variables, pleaaaaaase do not > use sum([ x for x in the_variables_i_want_to_add_together]). There is a Sum > function made just for that. It is a pity I had to do such things, but > otherwise adding n variables together result in a n^2 algorithm, while > linear time should be sufficient :-D > > This function is available this way : > > from sage.numerical.mip impot Sum > > And all the LP codes available in Sage use this Sum function instead of the > usual "sum" :-) > > Anyway, the code you are interestedin is defined in sage/numerical/mip. The > sums/comparisons between MILP variables are implemented in the MIPVariable > and LinearFunction classes you will find at the bottom of the file, and you > will also be interested by the add_constraint method, and the > solver-specific add_linear_constraint functions in the > sage/numerical/mip/backend_* files. > > > Nathann > > -- > 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-support > URL: http://www.sagemath.org -- 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-support URL: http://www.sagemath.org
