[Octave-bug-tracker] [bug #31742] sqp: incorrect order of removal of Inf bounds

[Rik]

Follow-up Comment #7, bug #31742 (project octave):

Excellent testing.  I always found the global variables here a bit of a hack,
but had never gone to the trouble of actually testing their performance.  I
applied your patch here
http://hg.savannah.gnu.org/hgweb/octave/rev/2726132f77f6.

While testing your patch with the example in the documentation I found a few
more problems with sqp (not your patch).  First, it doesn't always respect
bounds if only one bound is specified, such as -1,[].  It seems that in this
case the algorithm converges on a value for x(1) near -1.7 and the algorithm
stops because the stepsize becomes too small.  The return value for this case
is still 101, success, which it clearly isn't.  Perhaps we should use a
different return value to indicate this sort of stopping condition?  Secondly,
the problem seems to be with the magnitude of the upper bound in this case. 
If I use a smaller upper bound such as 10, rather than +realmax, then sqp
works.  In the same vein, if I use a vector of all Infs, then sqp also works
because the constraint is removed with your new code.  Perhaps, if the bound
is unspecified, the code should reduce to using +/-Inf rather than +/-realmax
so that the bound is never tested?

The second problem is a little more serious.  If I run the demo code and set
a smallish upper bound then the function crashes because lambda is empty.

[x, obj, info, iter, nf, lambda] = sqp (x0, @phi, @g, [], -10, 1)
error: sqp: operator *: nonconformant arguments (op1 is 5x13, op2 is 0x0)
error: called from:
error:   /home/rik/wip/Projects_Mine/octave-doc/scripts/optimization/sqp.m at
line 481, column 9

Since you seem to understand the algorithm pretty well it would help if you
took a look at that.  Be sure to pull a new copy of sqp.m from the repository
since I also changed a bit of the documentation which had repercussions for
some variable names in the code.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31742>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/