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 <[email protected]> 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.
>
>
>
_______________________________________________
Help-glpk mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-glpk
