Re: [boost] [math] RFC: comparison function objects

From: John Maddock (john_at_[hidden])
Date: 2006-04-24 12:51:27

> 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.