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

Ben Abbott bpabbott at mac.com
Sat Apr 5 19:09:40 CDT 2008


Might it be compatible with Matlab's variant?

http://www.mathworks.com/access/helpdesk/help/toolbox/optim/index.html?/access/helpdesk/help/toolbox/optim/ug/quadprog.html&http://www.google.com/search 
?client=safari&rls=en-us&q=matlab+quadprog&ie=UTF-8&oe=UTF-8

For the motivation of compatibility I expect many would be interested.

Ben


On Apr 5, 2008, at 8:03 PM, A. Scottedward Hodel wrote:
> Ages ago I wrote (in C) an interior point method for QP problems.   
> I've used it for some simulation work with control allocation.  If  
> there's interest, I could try to port this for Octave use.   It's a  
> first-implementation based on Boyd's book on Convex Programming.
>
> A. Scottedward Hodel hodelas at mac.com
> http://homepage.mac.com/hodelas/tar
>
>
> On Apr 5, 2008, at 5:58 PM, Joshua Redstone wrote:
>> I'm sorry I don't have an instance of the problem on a smaller data  
>> set.
>> RE debugging - I think it's good news it fails with such outrageous  
>> values and that the first element of X is one such value.  If I  
>> could get octave to build on my mac,  I'd be tempted to put  
>> temporary checks in the __qp__() routine that fail if there are any  
>> intermediate values greater than 1e+10.  Hopefully that would  
>> narrow it down a bit.
>> I may have some time to play with this a bit this weekend.
>> Josh
>>
>> On Sat, Apr 5, 2008 at 3:17 PM, Ben Abbott <bpabbott at mac.com> wrote:
>>
>> On Apr 5, 2008, at 5:58 PM, Thomas Treichl wrote:
>> Ben Abbott schrieb:
>> I've built octave using Apple's lapack/blas (i.e. vecLib), so the  
>> problem isn't directly related to the lapack/blas, correct?
>>
>> True. Then what about the difference between your PPC and our IAs?  
>> Just an idea...
>>
>> I get exactly the same solution on my PPC (G4) using a build from  
>> Feb 5.
>>
>>
>>
>> However, when I tried the release-3-0-x branch which I build  
>> yesterday (and passed all tests), it fails (also built with vecLib).
>> octave:8> result = 0.5*X'*H*X + X'*Q
>> result =  5.4445e+58
>> octave:9> tol = 10*eps;
>> octave:10> all ( X > LB-tol & X < UB+tol)
>> ans = 0
>> octave:11> all ( A_LB-tol < A_IN*X & A_UB+tol > A_IN*X)
>> ans = 0
>>
>> Hhhmmm...
>>
>> Thomas, when did you build last? The sources for one I'm running  
>> were pulled from John's archive archive 2-3 days ago.
>>
>> I've just pulled a new snapshot from John's repository and rebuilt  
>> everything. The same qr() results than before. However, somehow I  
>> think I still don't know what's going on. Is it possible to reduce  
>> that kind of problem to a much easier exercise (that also looks  
>> like a fail)?
>>
>> I agree this would make isolating the problem easier.  As I have  
>> not studied qr() I don't know if I can be successful ... but I'll  
>> kill a bit of time on it this weekend. If I'm successful I'll post  
>> to post immediately.
>>
>> Ben
>>
>> _______________________________________________
>> Bug-octave mailing list
>> Bug-octave at octave.org
>> https://www.cae.wisc.edu/mailman/listinfo/bug-octave
>



More information about the Bug-octave mailing list