Re: [Help-glpk] GLPK re-endrant

such as caching, making malloc/free perfect for multithreading, and removing all needs for TLS-like memory allocation. However, our patched version may still be broken, since we hadn't noticed the strtok and strerror issue. see http://bobpp.prism.uvsq.fr/ -- François Galea

[Help-glpk] different executions on different platforms

hi, We have noticed that executing the glpsol command-line solver on different machines with the same input data could lead to different execution. The number of simplex iterations / branch-and-bound nodes may differ, which leads to different performance. We have done our testings on three

[Help-glpk] glp_intopt and MIP presolve

to let the user program call the presolve whenever needed ? (For instance, to be able check the differences between the original LP and the presolved LP). Thank you, François -- François Galea ___ Help-glpk mailing list Help-glpk@gnu.org http

Re: [Help-glpk] KAAPI and glpk

, such as Kaapi. One of the available example programs is a simple MIP solver. The LP subproblems can be solved using GLPK, through the Glop API. please visit: http://bobpp.prism.uvsq.fr/ François -- François Galea ___ Help-glpk mailing list Help

Re: [Help-glpk] xmalloc, thread-safety

, this is perfectly possible. Thus, it is quite difficult to maintain a pool of BB nodes which can be handled in the same way by all the threads. -- François Galea Equipe OPALE - Laboratoire PRiSM Université de Versailles-Saint Quentin en Yvelines 45 av Etats-Unis F-78035 Versailles CEDEX Tél

Re: [Help-glpk] Stop BB at first feasible solution

Andrew Makhorin a écrit : I would like to know if there a possibility to make GLPK stop as soon as a feasible solution is found. It is possible only on api level. I was indeed looking for a solution on API level. Do you mean I nedd to use the new callback mechanism ? I thought there

Re: [Help-glpk] Huge problem.. can glpk solve it?

programming, known as the Hungarian method : http://www.ee.oulu.fi/~mpa/matreng/ematr1_2.htm I guess it should be possible to program it directly in an Excel macro. -- François Galea Equipe OPALE - Laboratoire PRiSM Université de Versailles-Saint Quentin en Yvelines 45 av Etats-Unis F-78035

Re: [Help-glpk] C++ wrappers for GLPK

Hello Robbie, Robbie Morrison a écrit : Hello GLPK list Two recent posts to this list discussed the use of wrappers to the GLPK API (application programming interface). Barry Roundree's posting (appended) mentioned a GLPK wrapper library. And Balazs DEZSO posted on a similar topic (Date:

Re: [Help-glpk] Thread-safety

Andrew Makhorin a écrit : What I need is indeed reentrability : what I want to do is solve different subproblems of the same problem in parallel, so each LPX is local to one thread only. This must work. In fact, I forgot to mention one crucial thing : even though each LPX is handled by