Boost logo

Boost :

From: John Maddock (john_at_[hidden])
Date: 2006-04-22 05:46:50


> template <typename T>
> struct compare_absolute_error : std::binary_function<T, T, bool>
> {
> T eps;
> compare_absolute_error(T eps_) : eps(eps_) {}
> bool operator()(T x, T y) const { return abs(x - y) < eps; }
> };
>
> This kind of operators occurs frequently in algorithms and are
> sometimes error-prone to write, so having a ready-made and well
> tested component
> can certainly be an advantage.
>
> Of course, we could (and should) provide a bunch of different
> comparison algorithms: absolute and relative in the first place, but
> there may be others. I believe it might be a little but useful
> addition to the math library.
>
> Main questions are:
>
> 1) Is there interest for this?

Yes, please.

> 2) What are the comparison algorithms to include?

I've already made a start, well not really a start, just a "I needed this
functionality to move on" throw it together sort of start here:
http://freespace.virgin.net/boost.regex/toolkit/libs/math/doc/html/math_toolkit/toolkit.html#math_toolkit.toolkit.relative_error_and_testing

Relative error in particular is a tricky one, you have to deal with:

One or both values may be zero.
One or both values may be denorms.
One or both values may be infinities.

So I guess if you wanted a really super-duper handle it all version you
would make it policy based:

* Values below a certain threshold are regarded as zero (so all denorms are
equivalent for example).
* Values above a threshold are regarded as effectively infinity.
* Absolute errors are used if the values are small enough.

Which of these you actually want to use in your application depend on the
QOI of the component you're testing I guess.

Personally I treat all denorms as zeros because if the result is a denorm
there probably isn't enough information content throughout the calculation
that led to the denorm to get an accurate value (if you see what I mean).

Anyway, just my 2c worth, please do feel free to jump in with something
better if you want!

John.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk