MaplePrimes - answers and comments on Question, Help with Optimization Workaround for Operator Form

method=nonlinearsimplex

pagan — Fri, 12 Nov 2010 08:29:01 Z

The (Nelder-Mead) method=nonlinearsimplex option of NLPSolve may work for you.

It does not require numerical derivatives, such as an explicit gradient of the objective. It does not seem to suffer the problem for which that cited workaround is devised. It allows an initial point to be specified (as you have done). And you have no bounds or constraints (which it does not allow).

You wouldn't have to use "operator form" with it, either.

number of arguments of EIG

acer — Mon, 15 Nov 2010 23:53:00 Z

Let's go back and look again at your posted code once more. Maybe there is a simple misunderstanding going on.

When you write the following, what did you intend?

     G[1] := fdiff(EIG, [1], [X[1], X[7]]);

Does `EIG` always expect two arguments, or seven arguments? If `EIG` expects seven arguments then you should call `fdiff` like this instead,

     G[1] := fdiff(EIG, [1], [X[1], X[2], X[3], X[4], X[5], X[6], X[7]]);

Note that the Vector argument `X` of `objfgradient` contains the values of the components of the 7-dimensional "point" at which you want the partial derivatives computed numerically. For `EIG` to be called correctly from within `fdiff` then all the seven numerical scalar elements of the point in question would be needed.

As an `fdiff` usage example, if one has a procedure/operator `f` that takes 5 arguments, then numerical estimation of the partial derivative with respect to the third argument -- evaluated at the given point [a,b,c,d,e] would be done with a call like fdiff(f, [3], [a,b,c,d,e]) .

I see now that my original example, of a procedure that takes only two arguments, is ambiguous. The call fdiff(f, [1], [a,b]) could just as easily be misinterpreted as only requiring the first and last argument in that list [a,b]. But in fact all entries of the given point are needed, as fdiff must pass them along when it in turn calls `f`. Sorry for any confusion.

If this is in fact the source of the problem then you'd also need to change the assignment to G[2], etc... Maybe something like this,

objfgradient := proc(X::Vector, G::Vector)
local Xlist, i, m;
   m := op(1,X);
   Xlist := convert(X,list);
   for i from 1 to m do 
      G[i] := fdiff(EIG, [i], Xlist);
   end do;
NULL;
end proc;

acer

fdiff?

petrivka — Mon, 15 Nov 2010 22:56:06 Z

@acer : I honestly don't understand very well how this fdiff function is working. I can evaluate the procedure EIG itself without any trouble at the initial point I provided, as well as at points close to it. Objf works just fine as well. It's the objfgradient, where the fdiff is contained, that I'm losing track of what's happening.

EIG will not return a float value unless all 7 input variables are provided. Is that what's giving fdiff such a hard time?

I've tried the DirectSearch package, but it doesn't seem to do as well at minimizing my function as Optimization, at least for my problem.