Re: [boost] [Boost-users] [Review] ITL review starts today, February 18th

Subject: Re: [boost] [Boost-users] [Review] ITL review starts today, February 18th
From: John Reid (j.reid_at_[hidden])
Date: 2010-03-04 09:16:53

Joachim Faulhaber wrote:
>> So it might be better to have
>> both continuous and discrete intervals as right-open by default and to allow
>> some mechanism whereby the user can choose to allow different runtime bound
>> types if they need them.
> 
> I agree, that right-open intervals are suitable as default. But I am
> afraid, for the continuous case, we can not guarantee that all
> operations can maintain such an invariant. BTW existing interval
> libraries e.g. boost::numeric::interval or FILIB++ work with closed
> intervals. Subtract a closed interval from an interval set with
> continuous domain_type  and you need open bounds.

I was suggesting that your design could feature sets/maps that only had 
right-open intervals. This would be the default in both continuous and 
discrete domains. If the user really wanted to use all the different 
interval bound types over a continuous domain then perhaps he/she could 
choose to do so via a template parameter. This would probably be a rare 
use case though.

> 
>> I have some further unrelated design questions/points:
>>
>> Is there a function to return the distance between two intervals?
> 
> hull(x,y).left_subtract(x).right_subtract(y).length();

This isn't quite right if y < x.

> 
> I admit this is not extremely elegant...
> I deliberately left functions and calculations out, that rely on
> distance measures, because, in the general case ITL intervals and
> interval containers only require an ordered domain type. So you can
> use strings, sequences or other data types that do not implement a
> distance measure.

See below.

> 
>> The default interval type is closed. Isn't right-open a more natural choice
>> for most applications?
> 
> Good question ... I tried to change this in the past but encountered
> problems with unsigned integral domain types that flipped to max_int
> by singular applications of decrement operator -- in the current
> implementation. May be I should check this point more thoroughly
> again. I could get rid of the unloved unon<T>() meta function. ...

You seem to suggest you apply operator-- on integral domains here. Why 
not make the distance between intervals available when the domain is 
integral? This would be similar to the availability of first and last 
when the domain is discrete.

> 
>> It makes interval subtraction slightly simpler for
>> example. I've always found right-open intervals an easier concept to think
>> about and they make coding easier although this library removes any concerns
>> about the latter.
>>
>> I would like to see interoperability with other boost libraries such as
>> boost.hash and boost.serialization. Both would be very useful for my current
>> application.
> 
> I haven't checked this yet. There should be some kind of basic
> interoperability through (segment) iterators and element_iterators.

I'm not sure what you mean by basic operability. I would like to take 
the hash value of an interval and serialize intervals, interval sets and 
interval maps.

I think this is a suitable way to make intervals hashable:

//
// Make intervals hashable.
//
namespace boost {
namespace itl {

template<
        class DomainT ,
        ITL_COMPARE Compare
 >
std::size_t
hash_value( interval< DomainT, Compare > const & x )
{
        std::size_t seed = 0;
        boost::hash_combine( seed, x.lower() );
        boost::hash_combine( seed, x.upper() );
        return seed;
}

} // namespace itl
} // namespace boost