In general, Optimization Toolbox™ solvers iterate to find
an optimum. This means a solver begins at an initial value *x*_{0},
performs some intermediate calculations that eventually lead to a
new point *x*_{1}, and then repeats
the process to find successive approximations *x*_{2}, *x*_{3},
... of the local minimum. Processing stops after some number of iterations *k*.

At any step, intermediate calculations may involve evaluating
the objective function and constraints, if any, at points near the
current iterate *x _{i}*. For
example, the solver may estimate a gradient by finite differences.
At each of these nearby points, the function count (

`F-count`

) is increased by one. If there are no constraints, the

`F-count`

reports the total number of objective function evaluations.If there are constraints, the

`F-count`

reports only the number of points where function evaluations took place, not the total number of evaluations of constraint functions.If there are many constraints, the

`F-count`

can be significantly less than the total number of function evaluations.

`F-count`

is a header in the iterative display
for many solvers. For an example, see Interpreting the Result.

The `F-count`

appears in the output structure
as `output.funcCount`

. This enables you to access
the evaluation count programmatically. For more information on output
structures, see Output Structures.

Sometimes a solver attempts a step, and rejects the attempt.
The `trust-region`

, `trust-region-reflective`

,
and `trust-region-dogleg`

algorithms count these
failed attempts as iterations, and report the (unchanged) result in
the iterative display. The `interior-point`

, `active-set`

,
and `levenberg-marquardt`

algorithms do not count
such an attempt as an iteration, and do not report the attempt in
the iterative display. All attempted steps increase the `F-count`

,
regardless of the algorithm.

Was this topic helpful?