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

From: Alberto Ganesh Barbati (abarbati_at_[hidden])
Date: 2006-04-25 13:37:32

John Maddock ha scritto:
>>> 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);
>>>
>> Interesting. The other posters are talking about function objects
>> because I started the discussion with them. The main reasons I did
>> that
>> is that function objects are more suitable to be passed as arguments
>> to algorithms because the compiler can inline them (more) easily.
>> Having
>> free functions could be a nice addition but they shouldn't replace
>> function objects entirely, IMHO.
> 
> I realise why they're used, but I'm struggling to think of an example where
> one would pass a function object that returns relative error to another
> function: in other words I'm looking for your motivation.

You may have the same generic algorithm (written as a template,
probably) that you may want to use with different methods of computing
errors, for example. For instance:

double total_absolute_error =
  std::inner_product(values.begin(), values.end(), estimates.begin(),
    std::plus<double>(), absolute_error<double>());

double total_relative_error =
  std::inner_product(values.begin(), values.end(), estimates.begin(),
    std::plus<double>(), relative_error<double>());

Anyway the whole point is about comparison, not calculation of the
relative error. The comparison strategy is what is most probably going
to be passed to algorithms so it's more suitably implemented through
function objects. I hope you agree up to this point. Well, now I see the
relative_error computation as a policy that customizes a comparison
object and also in this case it's more suitably implemented through an
object.

But enough words, I have uploaded a first implementation of what I have
in mind in the boost vault, so you can see what I mean. You will find it
in the "math - numerics" folder.

> Um, the problem I have with the asymmetric version, is this: which parameter
> is the "true" value?

The first one ;)

Jokes apart, if the programmer knows which is the "true" value (it might
happen, really!) he can pass it as the first parameter and use the
asymmetric version, otherwise he'll better use the symmetric version.

> Or to put it another way, it's way too easy to screw up and pass the
> parameters the wrong way around, and no amount of testing you do will ever
> detect that mistake (especially if you're getting spurious test passes as a
> result of your mistake, unlikely I realise but possible).  That's why I
> always test my code with a symmetrical version, just called 
> "relative_error".
> It's not quite what a mathematician would expect, but from a programming
> perspective it's more robust.

I know that most programmers will use the symmetric version, but that's
not a reason for not providing the asymmetric. The only thing is to
choose good names so that everyone is happy and (most importantly)
everyone knows what's he doing.

Ganesh