(
Jump to the original submission)
Thu 28 Feb 2013 09:21:42 PM UTC, comment #7:
I've reproduced the problem in Octave 3.6.3 / glpk 4.48 on FreeBSD 9.1 amd64.
Note that some default tolerances used by glpk() function are bigger than 8e-8. If I change 'tolbnd' to a smaller value, qp() finds the solution.
|
Tue 26 Feb 2013 04:59:46 PM UTC, comment #6:
Linux-x86_64 and Windows 32 bits.
|
Tue 26 Feb 2013 04:53:14 PM UTC, comment #5:
The problem is clear--that first element which is 0 in my case and 8e-8 in yours. I compiled a very vanilla glpk-4.47 with just -O2 as an option and similarly compiled Octave with the same vanilla -O2 but I don't see this problem. I'm running x86_64. Is your Linux 32-bit or 64-bit?
I think someone else will have to debug this as I can't reproduce it.
|
Sat 23 Feb 2013 01:46:16 AM UTC, comment #4:
The result on my computer:
abs (P(n-n_eq+1:end)) is a column vector of 0, except the first element that is: 8.08849339009994e-08
rtol = 1.49011611938477e-08
norm (btmp) = 9.61423041688342e-01
Also the secondary outputs of the glpk call are:
dummy = -8.08849339009994e-08
status = 180
|
Sat 23 Feb 2013 01:29:48 AM UTC, comment #3:
I upgraded to glpk-4.47 and am running the default branch (3.7.2+) under Linux and still can't reproduce this.
I set a breakpoint at line 366 of qp.m (the call to glpk) and executed the call to qp that results in "The problem is infeasible". On my computer the status code is 180. The results for the other variables, for comparison on the failing computer, are:
|
Fri 22 Feb 2013 09:08:59 PM UTC, comment #2:
I can reproduce the issue on the default branch (3.7.2+): under Linux with glpk-4.47 and under Windows/VS2010 with glpk-4.45.
|
Fri 22 Feb 2013 08:57:18 PM UTC, comment #1:
This works fine for me with version 3.6.1 on a Linux (not BSD) system. It is possible that the particular library versions of qp and glpk that you have are the source of the problem. I have glpk 4.38-1.
|
Tue 19 Feb 2013 10:54:50 PM UTC, original submission:
All matrices, which are used below, are saved in the attached file.
When qp() is called in the following way
it fails with status 6 'The problem is infeasible.'
However, when the known solution is given as initial guess
the function finishes successfully.
I've made a quick check and found out that the last part of this condition in qp.m fails
I suspect that the problem is related to tolerances used in qp() and glpk().
|
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach File(s):
Comment:
Depends on the following items: None found
Items that depend on this one: None found
Follow 2 latest changes.