octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Olaf Till
Subject: [Octave-bug-tracker] [bug #31742] sqp: incorrect order of removal of Inf bounds
Date: Sun, 05 Dec 2010 19:09:31 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.19) Gecko/2010102809 Iceweasel/3.0.6 (Debian-3.0.6-3)

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

To avoid misunderstandings: Of corse the value of the inequality
constraints is still checked in each iteration. Only isinf() is
checked only once, and the yielded index is applied unchanged in each
iteration.

Elements of h(x0) which are +Inf appear because some elements of x were
specified by the user to have no bounds by setting these elements bounds to
-Inf or +Inf. This means that these elements of h(x) are actually _no_
constraints, so they can be removed forever (the original comment at these
lines in sqp.m already mentions bounds).

The algorithm requires a gradient of the constraint function for
sensible action. Thats why h(x) is required to be continuous.

In particular, if elements of h(x) are Inf or -Inf, their gradient can not be
computed at all. One could weed out such values if they appear, by checking
isinf(h(x)) in each iteration. Under certain circumstances, this weeding out
could lead to finally achieving a solution nevertheless, but only by chance
(if h(x) gets non-Inf again by chance), and not by the intentional course of
the algorithm. I would not suggest to do that, I'd say such a h(x) is just
erroneous. Furthermore, this was clearly also not the intention before my
patch, since the check was not just for isinf(h(x)), but for (isinf(h(x)) &
h(x) > 0), which is true in the no-bounds specification (see 1st paragraph);
also, see the original comment:

## ... _never_ be active

(also true for the no-bounds specification, but not in our just
constructed case of h(x) _sometimes_ returning Inf or -Inf).


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]