
Boost : 
From: Guillaume Melquiond (guillaume.melquiond_at_[hidden])
Date: 20040308 14:26:05
Le lun 08/03/2004 à 20:08, Eric Niebler a écrit :
> Michael Stevens wrote:
> > The test case is very simple.
> >
> > #include <boost/numeric/interval.hpp>
> > #include <boost/minmax.hpp>
> >
> > int main()
> > {
> > boost::numeric::interval<float> a,b,c;
> > c = boost::std_max(a, a);
> > }
> >
> > gcc (2.95.3 and 3.3.1) is only warning "returning reference to temporary". I
> > am surprised this doesn't show up in more cases. Why gcc thinks it needs a
> > temporary here is beyond me
[...]
> The fix is to detect whether the unqualified call to max returns an
> lvalue or not and define the return type of std_max appropriately. Easy
> enough.
>
> What strikes me as odd with this overload, though, is that max(a,b) in
> this case will return something that is not equal to either a or b. That
> seems counterintuitive. Is this right?
Yes this is right :)
In interval arithmetic, all the functions are usually defined by
canonical set extensions. It is also the case for max. Consequently
max(A,B) is the interval {max(a,b); a in A and b in B}. When A and B
don't overlap, the result is A or B.
But it isn't the case when they overlap. And it isn't as much
counterintuitive as you seem to think. How would you define max(A,B)
when you have neither A < B nor A > B (it happens when A and B overlap)?
Getting A or B in that case would be counterintuitive.
Regards,
Guillaume
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk