Re: [boost] Review Request: Creasing (Sequence Properties)

Subject: Re: [boost] Review Request: Creasing (Sequence Properties)
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2010-01-27 12:57:30

Joachim Faulhaber wrote:
> Hi Grant,
> 
> 2010/1/24 Grant Erickson <gerickson_at_[hidden]>:
>> The creasing algorithm templates define four template functions for
>> determining the order properties of sequences, specifically:
>> 
>>    * Increasing
>>    * Decreasing
>>    * Strictly Increasing
>>    * Strictly Decreasing
> 
> 
> in your implementation of 'creasing' you provide the four specific
> algorithms is_[strictly_]{in_,de_}creasing while hiding the general
> algorithm is_creasing in namespace detail.
> 
> I'd suggest to implement only the latter. This would make your
> extension both more minimal and more general.
> 
> template <typename ForwardIterator, typename BinaryPredicate>
> bool is_ordered(ForwardIterator first, ForwardIterator last,
>   BinaryPredicate binary_pred)
> {
>   return std::adjacent_find(first, last,
>       std::not2(binary_pred)) == last;
> }
> 
> Although 'creasing' undoubtedly is a very enjoyable word it violates
> the principle of least astonishment. So I'd prefer 'ordered'.
> 
> Algorithm is_ordered can be used to express orderedness or sortedness
> for operators <, >, <= and >= but also can be used for arbitrary
> other strict or partial orderings.
> 
> is_ordered(worlds.begin(), worlds.end(), more_perfect<world>());
> 
> is_ordered not only allows to use arbitrary ordering relations,
> you can also apply the algorithm to check, if elements of a sequence
> all share the same equivalence class, if binary_pred is an
> equivalence relation:
> 
> is_ordered(people.begin(), people.end(), same_sex<person>());

I'm a little confused why there is such a narrow focus on ordering relationships here.  What seems to be the most general solution to this is a generic range adaptor that given a range over elements of type T returns an adapted range over pairs of elements of type T that are adjacent to eachother in the input range.  I'm constantly writing such adaptors to convert polygon vertices to polygon edges as pairs of vertices.  Combine that with a foreach or just a while loop and you can apply the predicate.  We can generalize the adjacent-pair-range-adaptor seperately from the foreach-element-in-a-range-apply-functor algorithm.  Marrying the two seems like gluing a hammer to a screwdriver and claiming to have invented a new tool.  As it happens we have boost libraries that provide a basis for each of these generally useful constructs.  It seems a little pointless to propose a library to combine them to solve a very specific problem.  Nobody is at a loss as to how to code up something to figure out whether elements in an iterator range are sorted, and nobody would or even should look in boost for such a simple thing.  Did the author skip the determining interest step and ask for a review prematurely, or am I missing something about the proposed library?

Thanks,
Luke