How to compare algorithms being solved by lsqnonlin() - matlab

Question

I have multiple algorithms trying to solve the same problem using lsqnonlin. The last 3 have one parameter fixed. How do I read the output here.
a) What does funCount mean?
b) Does having lower step size mean better result?
c) If firstOrderOpt is closer to 0, is it a better result?
Algo
Iterations
FunCount
StepSize
FirstOrderOpt
1
10
69
4.00E-10
3.00E-07
2
10
68
2.00E-09
2.00E-07
3
12
65
6.00E-11
1.00E-08
4
10
69
4.00E-10
3.00E-07
5
10
68
2.00E-09
2.00E-07
6
12
65
6.00E-11
1.00E-08

Answer 1

From the documentation, the fields of the lsqnonline output are
Field name
Meaning
irstorderopt
Measure of first-order optimality
iterations
Number of iterations taken
funcCount
The number of function evaluations
cgiterations
Total number of PCG iterations (trust-region-reflective algorithm only)
stepsize
Final displacement in x
algorithm
Optimization algorithm used
message
Exit message
Specifically addressing your questions,
a) funcCount is the number of times your input function was evaluated to obtain the result.
b) As you approach the optimal solution, a smaller step size may be needed to avoid "jumping" straight over it. It isn't really a good measure of having a "better result", but you should expect it to be small (otherwise you could be skipping over optima) but not so small that you get into the noise of numerical precision errors within your function.
A smaller stepsize will also slow the solver down, and likely lead to more iterations - you can see this reflected in your results table as the two rows with stepsize of order 1e-11 have more iterations than the others.
The StepSize is somewhat problem dependent, the related MathWorks documentation on Tolerances and Stopping Criteria may be helpful.
c) Please read the MathWorks documentation on the First Order Optimality Measure.
First-order optimality is a measure of how close a point x is to optimal. Most Optimization Toolbox™ solvers use this measure, though it has different definitions for different algorithms. First-order optimality is a necessary condition, but it is not a sufficient condition. In other words:
The first-order optimality measure must be zero at a minimum.
A point with first-order optimality equal to zero is not necessarily a minimum.
So a smaller firstOrderOpt indicates a better result, but does not necessarily give an estimate to the true optimum - if we had that then we would likely already know the true answer without the need for an optimser!
There is an OptimalityTolerance option within lsqnonlin, so you have control over how small the first order optimality must be for the solver to stop. Again, please see the docs.