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 |
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.
