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

Subject: Re: [boost] Review Request: Creasing (Sequence Properties)
From: Grant Erickson (gerickson_at_[hidden])
Date: 2010-01-25 12:56:34

On 1/25/10 6:18 AM, Stewart, Robert wrote:
> Grant Erickson wrote:
>> The creasing algorithm templates define four template functions for
>> determining the order properties of sequences, specifically:
>> 
>>     * Increasing
>>     * Decreasing
>>     * Strictly Increasing
>>     * Strictly Decreasing
>> 
>> The implementation is a fairly trivial composition of the STL
>> adjacent_find,
>> not2 and {greater,less,greater_equal,less_equal}.
> 
> What about types that only support operator <?  They are pretty common and
> operator >, operator >=, and operator <= can be implemented in terms of
> operator <, right?

Rob:

Thanks for the prompt feedback. Regarding the fundamental nature of operator
< and the syntactic sugar that is operators >, ¾ and „, sure:

   x > y ->   y < x
   x ¾ y -> !(y < x)
   x „ y -> !(x < y)

> (Obviously, detecting whether the other operators are defined and using them
> is better.

I am familiar with type traits; however, I am not familiar with operator
traits. Are you suggesting a (pseudocode) implementation such as:

    template <typename ForwardIterator>
    bool
    is_increasing(ForwardIterator first, ForwardIterator last)
    {
        typedef typename std::iterator_traits<ForwardIterator>::value_type
            value_type;

        if (is_less_equal_comparable<value_type>) {
            return detail::is_creasing(first,
                                       last,
                                       std::less_equal<value_type>());
        } else {
            return detail::is_creasing(first,
                                       last,
                                       std::not2(
                                         swizzle(
                                           std::less<value_type>()));
        }
    }

> Using a provided operator <= likely would
> be more efficient than synthesizing it from operator <.  The others are less
> likely to differ in efficiency.)
> 
> You could simply require all four operators, given the existence of
> Boost.Operators, but it would be easy enough to support a wider range of types
> with this library.

Failing the above example, if you could provide a more concrete example, I'd
welcome that.

Best,

Grant