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.