Chris, > Following yesterday's email, I decided to implement an error recovery > procedure that allows integer optimisation to continue after an error > in a heuristic (proximity search in this case). This is shown in the > two attached patches: env.patch implements the necessary > infrastructure to clean up after an error and proxy.patch shows how > proximity search can be modified to take advantage of this.
Unfortunately this procedure may not work. If an error is signaled via glp_error, consistency of glpk internal data structures is no longer guaranteed, so the only way to continue is to re-initialize the glpk environment that invalidates all glpk program objects. I think that a more robust way to prevent crashing is to revise all internal glpk routines to report an error code in case of failure; currently some of them (e.g. spy_dual) simply abort via glp_error. Of course, I mean only failures, not errors in program logic. Andrew Makhorin _______________________________________________ Help-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-glpk
