qp() in Octave 3.0.0 returns result egregiously violating input constraints

[Ben Abbott]

On Apr 6, 2008, at 3:42 PM, Gabriele Pannocchia wrote:
> Hi Josh,
>
>> Yes, feasibility is lost during the iterations, at iteration 187 for
>> me, and Ben observed it reporting infeasible solutions at iteration
>> 200.
>> It seems to be particular to the intel osx machines.
>> I think we're still not sure where the problem lies.
>
> Do you (and Ben) know if the initial point (computed by glpk) is
> feasible?
>
> Also, can you try to see what happens if you supply the attached
> feasible initial point (saved as the variable X0). Do you loose
> feasibility also in this case?
>

It appears to work for me.

octave:44> INFO
INFO =
{
   solveiter =  200
   info =  3
}

octave:45> OBJ
OBJ =  2.5372e-06
octave:46>

I tried modifying the order of the equations' rows using the attached  
function, mod_qp.m

I found that by reordering the rows, the problem did not diverge.  
However, in each instance the 200 iterations were reached.

I also tried to determine which rows were unique, by using the code  
below.

[jnk, n] = unique ([A;Q';H;LB';UB';A_IN]', 'rows');

When I solved the problem using only the unique rows (there are 119  
unique rows) ...

n = sort(n);
[X0, H, Q, A, B, LB, UB, A_LB, A_IN, A_UB] = mod_qp(n);
[X, OBJ, INFO, LAMBDA] = qp (X0, H, Q, A, B, LB, UB, A_LB, A_IN, A_UB);

The result is

OBJ =  2.5114e-05
octave:50> INFO
INFO =
{
   solveiter =  56
   info = 0
}

Assuming I haven't got something wrong ... Is this sort of behavior to  
be expected?

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_qp.m
Type: application/octet-stream
Size: 1553 bytes
Desc: not available
Url : https://www.cae.wisc.edu/pipermail/bug-octave/attachments/20080406/e49092ab/attachment-0001.obj