"Functions" in this context are calls to methods of the traits CostFunction, Gradient, Hessian, Jacobian, Operator, but also solver-specific ones such as Anneal (Simulated Annealing). Furthermore it includes user-created functions which we do not know about yet.
I think it should be possible to limit the total number of evaluations (all function evaluations summed up), as well as limiting the number of calls to individual functions. Ideally, users can also decide which subset of functions they think should be considered.
To be consistent with how the max_iters limit works, the information which function calls should be limited how, should probably also reside in the state (IterState, PopulationState) and access to them is probably via the State trait. The actual check should probably be performed in Executor after every iteration. However, that may cause the actual number of evaluations to exceed the set limit.
Alternatively it may be possible to include this into the Problem struct, by informing the solver if the limit is exceeded, but I'm afraid that this will cause too much code that is difficult to maintain. If implementing this requires changes to the individual solver implementations, then it is certainly the wrong path.
"Functions" in this context are calls to methods of the traits
CostFunction,Gradient,Hessian,Jacobian,Operator, but also solver-specific ones such asAnneal(Simulated Annealing). Furthermore it includes user-created functions which we do not know about yet.I think it should be possible to limit the total number of evaluations (all function evaluations summed up), as well as limiting the number of calls to individual functions. Ideally, users can also decide which subset of functions they think should be considered.
To be consistent with how the
max_iterslimit works, the information which function calls should be limited how, should probably also reside in the state (IterState,PopulationState) and access to them is probably via theStatetrait. The actual check should probably be performed inExecutorafter every iteration. However, that may cause the actual number of evaluations to exceed the set limit. Alternatively it may be possible to include this into theProblemstruct, by informing the solver if the limit is exceeded, but I'm afraid that this will cause too much code that is difficult to maintain. If implementing this requires changes to the individual solver implementations, then it is certainly the wrong path.