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

[Gabriele Pannocchia]

> It appears to work for me.
> 
> octave:44> INFO
> INFO =
> {
>    solveiter =  200
>    info =  3
> }
> 
> octave:45> OBJ
> OBJ =  2.5372e-06
> octave:46>

Do you also know if the starting point computed by glpk (if you do not
supply the starting point I sent) is feasible or not?

> 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?

It is hard to tell... You removed 40 variables from the problem, so that
this is not the same QP.

Gabriele