On Aug 26, 7:47 pm, Nathann Cohen <nathann.co...@gmail.com> wrote: > Hello ! > > > You could be interested in the approach implemented in FuncDesigner LP > > model:http://openopt.org/NumericalOptimizationForFuncDesignerModels#LP_example > > Maybe in future I'll add FuncDesigner examples for MILP and some more > > classes. > > I *AM* interested in this... Thanks for the information !!! I am > looking for ways to make LP easier in Sage ( it can be done now, but > it is far from being as easy as in the example you show... Could you > tell me how you deal with indexed variables, as x_1, ..., x_n ( and it > could have to be indexed 2 or 3 times ) ?
Yes, you can use indexation like some_oovar[i] or some_oofun[i] (probably with several indexes, or negative ones that are start from array end), however, I think it should be avoided if possible (you'd better split your oovar into several oovars). http://www.openopt.org/FuncDesignerDoc#Some_issues_to_be_aware As for arrays with ndim>1 they are not implemented in FuncDesigner yet and will be hardly implemented in nearest future, for the release 0.15 I intend to focus on stability. Also, I have difficulties with Automatic differentiation (for nonlinear functions) when ndim>1 (even for ndim <=1 it wasn't that easy). I don't want someone to spend lots of time and efforts for coding a FuncDesigner model and then get "Automatic differentiation cannot be done for the model yet". However, I think dot(some_fixed_array, some_oovar_or_oofun) will be ready till nearest FD release with some_fixed_array.ndim <= 2. > > Let me also note - statement "COIN-OR and CPLEX which have similar > > performances" is completely wrong. > > A colleague of mine who tested them seemed to say they had similar > performances (and he is likely to have spent quite a long time on > that :-) ), and the link you gave seems to confirm the fact that > "compared to GLPK, the solvers from COIN and CPLEX are way ahead". > There seem to be another gap between COIN and CPLEX, though, you are > right, I am just being kind to a colleague who did not try to betray > me :-) Maybe I have translated it wrong with my small knowledge of English. > > First of all COIN-OR project is a set of solvers (LP, NLP, etc), not > > an LP/MILP solver. > > I was talking about Cbc, I often do it as COIN if a bit more famous > than Cbc > > > At second, it is well-known CPLEX is too far ahead of any free MILP > > solver. > > See for example the bench by Hans Mittelmann (one of most > > authoritative), where CPLEX is 6 times faster of fastest free MILP > > solverhttp://forum.openopt.org/viewtopic.php?id=18 > > The interface with COIN which is to be ( I hope ) one day merged to > Sage uses Osi, which also provides an interface to CPLEX. I had awared of OSI, but I'm not skilled in connecting code of other languages to Python, that's why I hadn't go for it. > To build a > support for CPLEX, one would only need to replace the string "Cbc" by > "Cplex" in the source code, which takes O(1) time. I will be able to > do it myself pretty soon, so Sage will also be able to use CPLEX :-) > > In the meantime, and even if I only talk about its graph-theoretic > applications, Sage already gained a LOT from the integration of Cbc > and GLPK... I will do what I can from now on to integrate a good > support for MIP... This is very nice to hear, still I think it would be better to provide Python-OSI API instead of SAGE-OSI, it would benefit more wield auditory (PythonXY, EPD, mere Python-scipy users etc). Of course, it's up to you - mb you are SAGE developer at first. Regards, D. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
