[Octave-bug-tracker] [bug #66420] Rows and columns mixed up in sqp

[anonymous]

Follow-up Comment #5, bug #66420 (group octave):

[comment #4 comment #4:]
> I think that there is a misunderstanding of the section in question: It aims
> to give the (correct) mathematical *definition* of the gradient (I guess to
> give some background/explanations):

I don't think it's a misunderstanding because the cite below explicitly refers
to the _constraint_ functions, not the objective function "phi". Let me
include the beginning of the paragraph in question:

"The third and fourth arguments [i.e. the constraint functions g and h] may
also be 2-element cell arrays of function handles. The first element [...]"

> "The first element should point to the constraint function and the second
> should point to a function that computes *the gradient of the constraint
> function*:
> [ d f(x)   d f(x)        d f(x) ]
> transpose ( [ ------   -----   ...   ------ ] )
> [  dx_1     dx_2          dx_N  ]

I agree that the term "gradient" is not optimal, as the gradient is usually a
column vector. However, the formula (with the "transpose") is not prone to
misunderstanding but it is simply wrong here in this context (i.e. context of
the _constraint_ functions g and h).

> In fact, sqp expects the *Gradient* for phi (when provided - the Hessian is
> possible on top) and the *Jacobian* for g,h (when provided).

I agree on this part.

Whether the wording is changed or not, any given formulae should be correct
(or removed).


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66420>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature