Franck Stauffer wrote:
Ok...then we ought to discuss those extra parameters as well: 1. Precision: what should be its type? Return type would be natural, but it is problematic for complex integrands.
Leave that to the user (while providing sensible predefined possibilities).
2. How to evaluate if the desired precision is reached? In the code I uploaded I explicitely let the user use it's own predicate, which I would say is important especially as some people would like to compare things in ULPs.
This should be a template parameters. Decide that one parameter of the integration routine is an "Iterator-like" class that has a method: bool stop(const Integrator&). Then each user has the choice of the implementation of the routine with maximum flexibility. I use such a thing for gradient descent and this is very flexible. It even allows to decide that only a certain amount of time is allowed to do the integration, or some number of iterations, or some sophisticated error measurement !! With a little more care, we can even define hierarchical behaviours (multiscale). This function also allows the easy wrapping of the "Iterator-like" to output (debug) information during the computation. Theo.