Boost logo

Boost :

From: Matthias Schabel (boost_at_[hidden])
Date: 2006-12-07 15:29:04

> 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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at