Andrew, 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.
Specifically, two new functions are introduced, push_env and pop_env. push_env saves a copy of the environment block that will be used for error recovery. pop_env resets the error hook and terminal output state to the conditions they were in when push_env was called. In addition, if there was an error all memory allocated after the call to push_env is freed and the error state is cleared. These functions can be used in the following way: jmp_buf jump; ENV ctx; ... push_env(&ctx); if(setjmp(jump)) goto finish; glp_error_hook(hook, jump); The hook function just calls longjmp. >From this point on, any memory allocation will be freed on error, so it is important to avoid calling functions that can modify pre-existing problem objects. However, something like prob = glp_create_prob(); glp_copy_prob(prob, old_prob, 0); is OK (otherwise the whole mechanism would be pointless). Then before the end of the function, pop_env needs to be called: finish: pop_env(&ctx); All memory allocated after push_env needs to be freed before the call to pop_env (actually the label before it) otherwise it will be freed a second time in case of error. Overall, the mechanism is a bit limited, and not appropriate for general use. However it can be useful during integer optimisation to guard against errors in heuristics or maybe cut generation and pseudocost initialisation using strong branching. Best Regards, Chris Matrakidis
env.patch
Description: Binary data
proxy.patch
Description: Binary data
_______________________________________________ Help-glpk mailing list Help-glpk@gnu.org https://lists.gnu.org/mailman/listinfo/help-glpk