Dear Andrew, This seems to me the same issue we discussed:
http://www.mail-archive.com/[email protected]/msg00374.html Although i have removed the tiny coefficients as you proposed and i have also switched to equilibration scaling, i still have a bunch of problems where this issue remains and i get into an infinite loop. For example the problem here: http://reliablecomputing.eu/glpk/ was originally obtained on a Linux machine (but i am unable to reproduce it in the same environment), however i can reproduce the infinite loop in the Windows environment... Even if you cannot reproduce the problem, please have a look at the the problem instance given at the above link. Please help me: What else should i remove / fix to zero / do whatever is needed to either resolve this issue or realize that i will get into an infinite loop and abandon the procedure? For example i see int the dump.txt file that there is a row bound 2.01e-17 and an other row with the bound 1.75e+03. Can it cause this strange behaviour? Is it possible to set a predefined limit on the number of switches back to the primal simplex method (at least i would not get into an infinite loop)? I think i can implement this but it is a rather ugly "fix"... A feature request: could you please implement a function to dump the lp object in hexadecimal format? It is supported by the ISO/IEC 9899:1999 standard (7.19.6.1 The fprintf function and 7.19.6.2 The fscanf function; the a conversion specifier), or http://www.dinkumware.com/manuals/?manual=compleat&page=lib_prin.html Now, it is totally random if i can reproduce the issue using the decimal dump even in the same software and hardware environment. The chances would be higher with a hexadecimal dump. Many thanks in advance! Ali _______________________________________________ Bug-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-glpk
