Re: [Help-glpk] MIPGAP error with Octave

[Marcelo Pinto]

Hello Andrew,

I would be glad to add this important feature and rewrite the octave
glpk binding using the new version of glpk API. I gonna send a email
to the octave maintainers mailing list to talk about this question.

For my purposes, in addition to the other modifications that I had
done before, I modified the fragment that you have sent to me to:

. . .
if (errnum == LPX_E_OK || errnum == LPX_E_MIPGAP)
   {
     if (isMIP)
       {
         *status = lpx_mip_status (lp);
         *fmin = lpx_mip_obj_val (lp);
       }
     else
. . .

With that, the values status, fmin and xmin are returned as expected.

Thanks very much!
Marcelo.


On Thu, Mar 31, 2011 at 11:37 AM, Andrew Makhorin <address@hidden> wrote:
> Hi Marcelo,
>
> The following fragment
>
> . . .
> if (errnum == LPX_E_OK)
>    {
>      if (isMIP)
>        {
>          *status = lpx_mip_status (lp);
>          *fmin = lpx_mip_obj_val (lp);
>        }
>      else
> . . .
>
> which reports status and fmin, is bypassed, because in your case the mip
> solver returns LPX_E_MIPGAP, not LPX_E_OK, to indicate that the search
> has not been completed.
>
> Best regards,
>
> Andrew Makhorin
>
> PS: I'd like to note that your code uses obsolete glpk api routines
> (prefixed with lpx_). If you have a time and wish, I could help you to
> reimplement the code using the standard glpk api. I'm not familiar with
> Octave internals, however, I could rewrite the glpk function.
>
>
>