[Help-glpk] (no subject)

[Chris Matrakidis]

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