Re: [Help-glpk] [Bug-glpk] [Fwd: Octave glpk() possible bug]

[Robbie Morrison]

Hello Andrew

First up, you need to join the [help-glpk] in
order to engage further:

  http://www.gnu.org/software/glpk/#lists

In addition, this might not be a bug but rather a
user-domain issue?  :)   Else it might be an
Octave issue?  And a matter for the Octave
crowd.

In any case, I cross-posted this back
to [help-glpk].

------------------------------------------------------------
To:           address@hidden
Subject:      [Bug-glpk] [Fwd: Octave glpk() possible bug]
Message-ID:  <address@hidden>
From:         Andrew Makhorin <address@hidden>
Date:         Mon, 03 Jun 2013 09:47:42 +0400
------------------------------------------------------------

-------- Forwarded Message --------
From: Andrew J. Lewis <address@hidden>
Reply-to: "Andrew J. Lewis" <address@hidden>
To: address@hidden
Subject: Octave glpk() possible bug
Date: Mon, 3 Jun 2013 06:40:59 +0100

> Hi!
>
> I have successfully run our program in Matlab, but
> when I ported it substituting glpk() for
> bintprog() the program only returns an answer for
> low numbers of input values, which is
> insufficient.
>
> I can make Octave work for <=5 input values, but
> when I try and run the amended program with the
> settings which I ran on Matlab, I get the
> following output:
>
> octave-3.2.4.exe:2> OctaveBeeswax
> GLPK Simplex Optimizer, v4.42
> 100 rows, 100 columns, 1058 non-zeros
> Preprocessing...
> 100 rows, 100 columns, 1058 non-zeros
> Scaling...
> A: min|aij| = 1.000e+000 max|aij| = 1.000e+000 ratio = 1.000e+000
> Problem data seem to be well scaled
> Constructing initial basis...
> Size of triangular part = 38
> 0: obj = 1.200000000e+001 infeas = 1.800e+001 (62)
> 26: obj = 1.200000000e+001 infeas = 1.800e+001 (40)
> PROBLEM HAS NO FEASIBLE SOLUTION

This means that the problem you submitted has been
proved infeasible by GLPK.  Note the word "proved".

You should be able to export the problem that GLPK
was "supplied" (at least I hope you can under
Octave) and examine it directly using GLPSOL and
any related tools at your disposal.  This strategy
effectively removes any issues to do with your
inputs, data preparation, Octave's behavior, the
Octave/GLPK interface and so on.

The other issue concerns bad scaling and related
numerical issues.  If you export the problem (as
just indicated), you can check how well or badly
scaled it is, apply various scaling routines, and
so on.  The insights gained here can then be used
to tune you GLPK call (although Octave may not
necessarily expose the entire suite of APIs
offered by GLPK to the Octave calling
environment).

> glp_simplex: unable to recover undefined or non-optimal solution
> status = 213
> countcir = 0
> opt_positions = [](0x0)
> octave-3.2.4.exe:3>
>
> I would be very grateful, please, for your
> opinions as to why repeatedly Octave fails to find
> solutions when Matlab does? I have tried every
> combination, including generating test data in
> Excel.

Frustrating I know.  But there should be an
explanation somewhere.

> Best regards,
>
> Andrew J. Lewis MSc, FLS, MRI
> Simul Systems Ltd
> Chelmsford, Essex, UK
> www.simulsystemsltd.co.uk
> M:+44 (0)7710 588318
> F:+44 (0)705 361 1341
> A member of Chelmsford Innovation Group - a "Smart Swarm" business
self-help group

HTH, Robbie
---
Robbie Morrison
PhD student -- policy-oriented energy system simulation
Technical University of Berlin (TU-Berlin), Germany
University email (redirected) : address@hidden
Webmail (preferred)           : address@hidden
[from Webmail client]