Closed ViralBShah closed 12 years ago
Hi Viral, sorry for answering this late, I've been extra busy lately. The GLPK interface should be almost complete, but I didn't test all of it. I actually only tested in some depth the functions which are used by linprog.jl, i.e. the core functions. One possible course of action would be trying to port C programs (which should be fairly trivial) and check for bugs, but this may get time-consuming if done thoroughly. The missing functions are mostly advanced tweaks for the branch & cut algorithm, if I remember correctly. They should be easy to implement anyway, for the most part, albeit tedious. What is more concerning is that some of the functionality requires function pointers, and I don't know if it's possible at all to provide those via Julia. One more thing which should be done is creating a nicer interface for options, flags and return values (maybe wrapping them in Julia objects, so that e.g. the return value could be printed as something meaningful rather than a number which the user has to look up in the GLPK manual to make sense of). I should also update the GLPK version. I could surely write some documentation, but given the current state, as described above, it would be a stub, probably. My main setback on the whole project of improving the GLPK interface was actually that I wanted to look into alternative LP solvers (the ones you pointed me to), whenever I find the time.
To summarize, some short term goals which I could do in a reasonable time may be:
Is that OK? Any suggestions (especially about priorities)?
What you suggest seems like the way to go for now to complete glpk integration.
-viral
On 13-Jun-2012, at 2:45 AM, Carlo Baldassireply@reply.github.com wrote:
Hi Viral, sorry for answering this late, I've been extra busy lately. The GLPK interface should be almost complete, but I didn't test all of it. I actually only tested in some depth the functions which are used by linprog.jl, i.e. the core functions. One possible course of action would be trying to port C programs (which should be fairly trivial) and check for bugs, but this may get time-consuming if done thoroughly. The missing functions are mostly advanced tweaks for the branch & cut algorithm, if I remember correctly. They should be easy to implement anyway, for the most part, albeit tedious. What is more concerning is that some of the functionality requires function pointers, and I don't know if it's possible at all to provide those via Julia. One more thing which should be done is creating a nicer interface for options, flags and return values (maybe wrapping them in Julia objects, so that e.g. the return value could be printed as something meaningful rather than a number which the user has to look up in the GLPK manual to make sense of). I should also update the GLPK version. I could surely write some documentation, but given the current state, as described above, it would be a stub, probably. My main setback on the whole project of improving the GLPK interface was actually that I wanted to look into alternative LP solvers (the ones you pointed me to), whenever I find the time.
To summarize, some short term goals which I could do in a reasonable time may be:
- do some more testing
- complete the implementation of what can be completed (leaving the rest on hang)
- advance the glpk version
- write a manual stub
Is that OK? Any suggestions (especially about priorities)?
Reply to this email directly or view it on GitHub: https://github.com/JuliaLang/julia/issues/923#issuecomment-6283185
Closed by ee9933f93d4cc16149392977056d9e2a57d1830a
There are still a bunch of functions missing, related to graph&networks (not strictly related to linear programming...) and latest additions to the GLPK library (i.e. SAT solvers); I will add hose in the future.
Hi @carlobaldassi
Is the GLPK interface ready for usage? If so, can you document it in the manual? In glpk.jl, it suggests towards the end that there are many more functions to be added. We can enable the building of GLPK in the deps then as part of the default build.
Eventually, this is something that will live in its own package and have its own lifecycle, but until then, it would be nice to have for general usage.