
Boost : 
Subject: Re: [boost] [Review:Algorithms] Order of args to clamp
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 20110925 17:56:13
On Sun, Sep 25, 2011 at 10:48 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> on Sun Sep 25 2011, Steven Watanabe <watanabesjATgmail.com> wrote:
>
> >> Here's an exercise:
> >>
> >> 1. Write down the documentation for both the multitype and singletype
> >> "clamp" algorithms. Describe both the concept requirements on the
> >> algorithm parameters, and the result of each algorithm (without
> >> making reference to its implementation).
> >>
> >
> > It seems fairly straightforward. All that's necessary
> > is to require that comparing objects of different types
> > is equivalent to converting to the same type and then
> > comparing and define the result to be the same as though
> > we converted first and called the single type version.
>
> So, do the exercise. And, BTW, which of the types involved is "the same
> type" in this case?
>
Okay, I'll try.
clamp(T x, L lo, H hi) > common_type<T,L,H>::type
Let U = common_type<T,L,H>::type.
Precondition: operator< defines an ordering on objects of type U. For any
2 objects a and b of types A and B, respectively, where A and B are each one
of {T,L,H}, a < b is equivalent to (U)a < (U)b. !(hi < lo).
[Note: I'm not sure yet precisely what "ordering" would be desired here
(probably a "strict weak ordering" is sufficient, as for many other STL
algorithms, but I confess I'm a bit rusty on various ordering properties),
and it should certainly be specified if you want to be precise, but it's the
same ordering as would be required for clamp(T,T,T), so it's somewhat
tangential to this exercise.]
Returns: If x < lo or hi < x (these are mutually exclusive assuming an
appropriate precise ordering), returns (U)lo or (U)hi, respectively.
Otherwise, returns (U)x.
[Note: I believe the above requirements yield at least 2 nontrivially
different implementations: (x < lo ? lo : hi < x : hi ? x) or (hi < x ? hi :
x < lo ? lo : x).]
Is this what you had in mind?
>> 2. Demonstrate that the multitype algorithm does what the single type
> >> algorithm does when passed only a single argument type.
>
Trivial; common_type<T,T,T>::type == T. The only simplification I see above
is that one of the preconditions is now trivial.
> >> 3. Imagine yourself wanting to clamp an int. Compare the documentation
> >> and reasoning you'd have to go through to satisfy yourself that the
> >> algorithm does what you want in each case.
>
 U == common_type<int,int,int>::type == int
 operator<(int,int) is an appropriate ordering on int's
 In either case, I'd have to verify !(hi < lo).
Preconditions satisfied, so I'd expect the algorithm to return x if x in
[lo, hi], and lo or hi, as appropriate, otherwise.
It's easy to wave one's hands about how straightforward it seems when
> you aren't looking at the actual realization. Show me how it actually
> plays out and then we'll see if the flexibility is worth the
> complication.
>
I don't see too much additional complication. I feel like I'm missing
something, though.
 Jeff
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk