Sure. The advantage to have a library solution is that it can handle corner cases better than a naive implementation.
Yep, this is something lots of people write believing it to be trivial and then end up fixing all the corner cases.
So I guess if you wanted a really super-duper handle it all version you would make it policy based:
I agree that we should provide as much customization as possible, but not more. In particular, I would use policy classes only if necessary, preferring multiple functors instead of one single functor with multiple policies. The task is perceived by a lot of programmer as trivial (although it isn't) and if the class is too complicated people might get discouraged and won't use it.
True.
* Values above a threshold are regarded as effectively infinity.
Is this necessary? I mean, that might be useful if we want to really compute a meaningful estimate of the relative error, but in this case we simply want to check if the relative error is smaller than a (hopefully small) value.
Actually probably not :-)
* Absolute errors are used if the values are small enough.
That might be a different algorithm. I would keep both relative-error and relative-error-or-absolute-error-if-values-small-enough. They both sounds right in different use cases.
Yep, and in fact once you have the basics sorted out it's trivial to create a thin wrapper that implements a policy like that if you need it.
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).
I think I understand and I partially agree. However it's not the fact that denormals are probably already inaccurate that worries me (the library should not make assumptions on how the data has been obtained) but rather that the division by such a small number might produce an inaccurate, and therefore useless, result.
Yep, good point. BTW I notice in other messages that folks have been talking about a function object for this, but.... what use would that be for? At present I can't see anything simpler and easier to use than just a free function: template <class T> T relative_error(T, T); Regards, John.