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. 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.
If there is a push to begin thinking about numerical libraries to be incorporated into Boost, I would vote to think seriously about having a return type that includes error estimates (as GSL does with it's result type or, perhaps, something like the measurement class I threw together as a demo for mcs::units, attached). If implicit conversion to the result type was allowed, it would be transparent to functions that didn't care about errors and visible to those that do. As far as I can see, precision needs to be the same type as the return type since it represents uncertainty in the latter. That is, the range of possible return values would be [result - n*error, result + n*error]. Do you have a case in mind where this isn't true? Also, though I haven't looked closely at it, it seems like integrators, in 1D at least, are general accumulators and might fit into the Boost.Accmulators framework nicely... Matthias ---------------------------------------------------------------- Matthias Schabel, Ph.D. Assistant Professor, Department of Radiology Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) matthias at stanfordalumni dot org ----------------------------------------------------------------